Hey @Kenshin3800 I am just a user sharing the same problem as you, and having the same feelings about it as you do.
I thought I might as well bump this thread.
I am also a tech lead with over twenty years of experience in the software & service industry, more than ten as a software engineer. I am pretty confident about my technical acumen.
In my own setup, Plex runs inside a container (Docker) on a home server. Port forwarding is configured on the router, with a straight mapping from port 32400 on the external interface to port 32400 on the server IP.
I believe I am running the container in bridge mode, with yet another 32400/32400 mapping - bottom line: there is a straight line of communication from the outside world to the Plex instance.
I am seeing exactly the same symptoms. My server is reported as connected for 20 seconds (or so), then goes down. Then comes back up.
The sense I get is that whichever heartbeat or keep-alive service running on the Plex infrastructure (remote) has a timeout that doesn’t mesh with the fact I am in Asia. Ie. said heartbeat is probably run from some central server based near the location of Plex headquarters, and it’s running with settings that are currently too optimistic.
The issue is extremely clear and the timing is extremely precise.
My second pet peeve is that I tried to connect directly, because when my wife is at home, there is no reason for her to endure the agony of a remote server roundtrip when she just wants to pop a few pictures, or start watching a movie.
For some reason, Plex seems to actively discourage that and the feature doesn’t work.
Now, I suspect that the reason is an intention to track usage; which is a problem. Both ethical and technical. I am paying for a service. I am not paying to see functionality disabled because the “provider” wants to increase their own leverage for profit.
I realize that this might come across as harsh, but I am getting overly tired of limitations like this, whether coming from inappropriate intent or simple misjudgment.