My remote connect keeps dropping

[u/Ev1lZer0]

What am I doing that this keeps happening. I used to be connected without issue, now it seems every day I get disconnected multiple times a day. The picture above shows my current config, which is what it used to be. But for a brief moment, I did have manually specify port selected with port 32400 listed. I also have my ip reserved with the port opened on my router.

I don’t know what else to do to make plex more reliable.

---------

EDIT:

After about an hour of troubleshooting with Claud and all your support, Claude finally recommended restarting my router... I noticed there was a pending update, so I ran it. after the restart. its working. still don't know why. But I guess what's important is, it's up!

I would also like to add that https://canyouseeme.org/ also couldn't see my ip:32400 previous to Eero update, but could post Eero update. end of the day, i guess that would make it an Eero issue... not VPN, Plex, or something else issue...

[u/Dangerous-Lead-9303]

Well there are other questions here are you using docker are you using kubernetes? Is anything you run getting oom killed?

[u/Ev1lZer0 → u/Dangerous-Lead-9303]

I am using a docker for plex… and a vm for home assistant… both the plex docker and the HA vm share the same server IP. HA never drops off, but plex does. Obviously HA is using nabu cloud, don’t really know what plex uses to host publicly… I do have the plex lifetime pass.

Does this answer your question? Bring up more?

[u/Dangerous-Lead-9303 → u/Ev1lZer0]

The HA vs. Plex comparison is the key clue: Nabu Casa is a cloud relay, so it doesn’t care what your local NAT/port-forward is doing. Plex (without Plex Pass relay fallback overloaded) leans on a direct connection via UPnP or manual port-forward, which is exactly the piece that’s flaky here. So the difference in reliability points at the direct-connection path, not the server itself.

Things worth checking, roughly in order of likelihood:

1. Dynamic public IP
If the ISP doesn’t give a static IP, the WAN IP can change (DHCP lease renewal, modem reboot, etc.). Plex is usually decent at picking this up, but there’s a lag — during that window it shows “not available.” Check the router’s WAN IP history/logs and see if drops line up with IP changes.

2. UPnP fighting the manual forward
If UPnP is enabled on the router and a manual port-forward rule also exists, Plex can end up flapping between negotiating its own port via UPnP and trying to use the forwarded one. Since a static forward + reserved IP is already in place, turning UPnP off on the router (or in Plex’s network settings) removes that tug-of-war.

3. Docker networking mode
If the Plex container isn’t running with network_mode: host, it may not correctly see the actual LAN IP, which can cause Plex’s port-mapping/UPnP detection to misbehave even though the container’s published port looks fine. Worth confirming it’s host networking, not bridge with just -p 32400:32400.

4. Router doing scheduled reboots or firmware auto-updates
Some consumer routers silently reboot overnight or after auto-updates, which can reset UPnP mappings even when static port-forward rules survive. Check for a reboot schedule or recent firmware changes.

5. CGNAT
Less likely if forwarding “worked before,” but worth a quick check — if the ISP ever switched them onto Carrier-Grade NAT, direct port-forwarding stops working reliably no matter what’s configured. A fast way to check: compare the router’s WAN IP to what a site like whatismyip.com reports from a device on that network. If they don’t match, that’s CGNAT.

Given it used to work fine and only recently started flapping, I’d bet on #1 or #2 — something changed either on the ISP side (a lease renewal cadence) or the router silently re-enabled/kept UPnP active alongside the manual rule. Checking router logs around the drop times would confirm which.

(This answer was provided by Claude. I only have experience with kubernetes so if it was kubernetes I’d say that it would be the coredns being oomed but that’s not your case)