# Plex Remote Access Issues **URL:** \ **Category:** Remote Access\ **Tags:** server-linux\ **Created:** [June 17, 2026, 3:18am UTC](https://forums.plex.tv/t/plex-remote-access-issues/939763 "2026-06-17T03:18:50Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![awfulfalafelwafflerofl](https://avatars.discourse-cdn.com/v4/letter/a/4491bb/32.png) [@awfulfalafelwafflerofl](https://forums.plex.tv/u/awfulfalafelwafflerofl)\ **Post date:** [June 17, 2026, 3:18am UTC](https://forums.plex.tv/t/plex-remote-access-issues/939763/1 "2026-06-17T03:18:50Z")
Server Version#:1.43.2.10687 Player Version#:4.159.0 I’m having trouble getting Remote Access to stay active. I’ve been working with ChatGPT to diagnose the issue for close to 8 hours now with no success, and it eventually suggested I come here to ask for help. What it can’t seem to figure out is: [Plex.tv](http://Plex.tv) still reports `connectivity=0`. And therefore: ```auto Mapped - Not Published (Not Reachable) ``` It determined that: ✅ HTTP works to the public IP ✅ HTTPS works to the public IP ✅ Port 32400 is open ✅ Plex responds correctly ✅ [Plex.tv](http://Plex.tv) registration succeeds Any ideas? Do you need more information? ---
**Author:** ![tom80H](https://sea1.discourse-cdn.com/plex/user_avatar/forums.plex.tv/tom80h/32/19753_2.png) [@tom80H](https://forums.plex.tv/u/tom80H)\ **Post date:** [June 17, 2026, 4:56am UTC](https://forums.plex.tv/t/plex-remote-access-issues/939763/2 "2026-06-17T04:56:44Z")
AI tends to give all kind of solutions… some might be rooted in reality, others not. Especially when its information is based on forum posts where users report some wild trial & error procedures that just didn’t work. # Did you already have a look at the related troubleshooting support article? [https://support.plex.tv/articles/200931138-troubleshooting-remote-access/](https://support.plex.tv/articles/200931138-troubleshooting-remote-access/) # There’s also a guide with some more details on how to troubleshoot remote access issues. Personally, I would start confirming that the port forward is working (=visible from outside your home network) and there’s no CGNAT (=public IP seen from outside your home network matches the WAN IP of your router) — both steps can be done with a service like [canyouseeme.org](http://canyouseeme.org) Based on the log snippet it might also be worth to check if Plex is able to properly talk to its online backend (e.g. Plex URLs are resolving properly → DNS, or no content/connections blocked). [https://forums.plex.tv/t/the-basics-of-remote-access-troubleshooting/769517/1](https://forums.plex.tv/t/the-basics-of-remote-access-troubleshooting/769517/1) ---
**Author:** ![tiki\_plex](https://avatars.discourse-cdn.com/v4/letter/t/b5ac83/32.png) [@tiki\_plex](https://forums.plex.tv/u/tiki_plex)\ **Post date:** [July 19, 2026, 7:30am UTC](https://forums.plex.tv/t/plex-remote-access-issues/939763/3 "2026-07-19T07:30:12Z")
_Same issue here (Docker/LinuxServer.io image, 1.43.3.10828, Unraid host, host networking). Same checklist as OP — public IP/port reachable from outside, port forward confirmed, Plex responds correctly, server registered with [plex.tv](http://plex.tv) (presence=“1” via the resources API) — and it still drops out of client server lists (tested with Plex Web, Varys on iOS)._ _One thing I dug up that might be a useful data point: the debug log shows the hourly PublicAddressManager cycle consistently ending in_ MyPlex: mapping state set to ‘Mapped - Not Published’. MyPlex: Last published value didn’t change, we’re done. _— and this happens identically whether the server is currently reachable for clients or not, so it doesn’t look like a useful health signal on its own. What did change things: after a full container restart, the publish sequence actually went through two attempts —_ Published Mapping State response was 422 […retry ~15s later…] Published Mapping State response was 201 mapping state set to ‘Mapped - Publishing’ → ‘Mapped’ _— so the [plex.tv](http://plex.tv) publish endpoint itself seems to reject the first attempt fairly often, and there’s apparently no retry logic on the server side to recover from that once it settles into “Not Published” — it just stops trying (“didn’t change, we’re done”)._ _Only reliable fix I’ve found is restarting the container — currently doing that 3x/day as a workaround, which obviously isn’t great for anyone actively watching anything when it hits. Would be good to know if this is a known issue on Plex’s end (backend publish/rate-limiting?) rather than something client-side troubleshooting can actually fix — the “confirm your port forward” checklist doesn’t really apply once you’ve already confirmed it’s fine._