Plex API not updating "custom server access URL"

Plex Media Server
1

Server Version#: 1.43.3.10861-07dfddaeb
Player Version#: All players

When updating the “Custom server access URL” it doesn’t seem to be reflecting on Plex’s API endpoint: https://clients.plex.tv/api/v2/resources

It shows domains for the preferred network interfaces, but not the custom server access URL.

This means the plex clients aren’t able to connect to my server as they attempt all the ones listed in that API response which is missing the custom URL that they need to use.

For what it’s worth, it was working initially – I erroneously changed the “Custom server access URL” field and then changed it back a few days later. Since then it has not worked.

It seems all is working fine on my end. My Plex process is making HTTP requests to the Plex server with the IP I need:

HTTP requesting PUT https://servers.plex.tv/devices/REDACTED
  ?Connection[][uri]=http://100.116.64.108:32400 #===> This is the one I care about
  &Connection[][uri]=http://192.168.68.72:32400
  &Connection[][uri]=http://172.17.0.1:32400
  &Connection[][uri]=http://172.18.0.1:32400
  &Connection[][uri]=http://172.20.0.1:32400
  &Connection[][uri]=http://172.19.0.1:32400
  &httpsEnabled=1
  &httpsRequired=0
  &dnsRebindingProtection=0
  &X-Plex-Token=xxxxxxxxxxxxxxxxxxxx

This is the response from the resources endpoint:

<resources>
  <script/>
  <resource name="REDACTED" product="Plex Media Server" productVersion="1.43.3.10861-07dfddaeb" platform="Linux" platformVersion="7.0.0-29-generic" device="Docker Container" clientIdentifier="REDACTED" provides="server" ownerId="" sourceTitle="" publicAddress="REDACTED" accessToken="REDACTED" searchEnabled="1" createdAt="2026-06-18T19:43:06Z" lastSeenAt="2026-08-15T06:44:53Z" owned="1" home="0" synced="0" relay="0" presence="1" httpsRequired="0" publicAddressMatches="1" dnsRebindingProtection="0" natLoopbackSupported="1">
    <connections>
      <connection protocol="https" address="192.168.68.72" port="32400" uri="https://192-168-68-72.REDACTED.plex.direct:32400" local="1" relay="0" IPv6="0"/>
      <connection protocol="https" address="172.17.0.1" port="32400" uri="https://172-17-0-1.REDACTED.plex.direct:32400" local="1" relay="0" IPv6="0"/>
      <connection protocol="https" address="172.18.0.1" port="32400" uri="https://172-18-0-1.REDACTED.plex.direct:32400" local="1" relay="0" IPv6="0"/>
      <connection protocol="https" address="172.19.0.1" port="32400" uri="https://172-19-0-1.REDACTED.plex.direct:32400" local="1" relay="0" IPv6="0"/>
      <connection protocol="https" address="172.20.0.1" port="32400" uri="https://172-20-0-1.REDACTED.plex.direct:32400" local="1" relay="0" IPv6="0"/>
    </connections>
  </resource>
</resources>

It seems the Plex API is not updating this resource for some reason – I would greatly appreciate some help.

2

To add to this, I’m using tailscale for secure remote access.

The plex Docker container successfully sees the tailscale0 network interface in /sys/class/net and /proc/net/dev.

I’m not sure if it’s noteworthy, but the tailscale interface is omitted from the “Preferred network interface” dropdown in the web UI.

3

Another update – adding another 192.168.*.* address instantly updates as the API response shows the value immediately.

This means it isn’t a caching issue.

Either the tailscale IP is being explicitly ignored by Plex or there is some defect that is preventing it from being added.

Still stuck here…

4

A few of us have confirmed the same behavior over on Reddit. It looks like they’re restricting the tailscale subnet.

Others have said you can still use the tailscale magic dns name for the url. I am able to use the url if I have a plex pass on the server. On a test server I have, with no plex pass, I can’t use either the ip or the dns.

5

I can’t get my head around the rationale for this decision - does the Plex team respond here? I would at least like to know why they’ve done this as they’ve effectively removed functionality from the product after I purchased my plex pass.

6

Not sure if it’s a bug or intentional. They do respond, to some threads, so will have to wait and see if they come back with any info on this.

My test server (with no plex pass) still has the tailscale ip in the field and it’s published, but if I add a new ip to the field in the tailscale subnet, it won’t publish that one. I don’t want to remove the working one to see if it lets me put it back, because I assume it won’t.

7

The rationale for what decision? Decision implies intent.

Check to see what’s published here;
https://plex.tv/api/resources?includeIPv6=1&includeHttps=1&includeRelay=1&X-Plex-Token=

Put your token after the =.

8

The decision to silently drop IPs within the tailnet CIDR range. That endpoint returns the same list as what I provided.

9

this is unfortunate. Is there any workaround for users that are stuck behind a CGNAT and needs to rely on a VPN to access my server remotely? I have plex pass for what that’s worth

10

Commenting here as I have the exact same issue with my Tailscale IP not being published. Hoping Plex Support will review this and resolve the issue soon.

11

Same issue here. I have Plex Pass and recently moved my server from a wireless to a wired connection. I updated my custom server URL because I thought that had been a culprit in something unrelated, now I can’t access my server from outside of my home because I’m behind a CGNAT. What’s up Plex, are you going to help us?

12

There are reasons not to accept or publish RFC6598 100.64.0.0/10 addresses. Plex’s position makes sense for their userbase and end-user service discovery model.

RFC1918 private addresses shouldn’t be reachable between organizations. But RFC6598 addresses might be reachable by another entity, another ISP customer, or another end user.

There is no globally meaningful interpretation of 100.116.64.108. Even if it isn’t an acute security concern, it’s still an identity and ambiguity concern.

It’s also not something I would necessarily expect Plex to facilitate, since it’s often used to bypass the paywalled remote access features.

I’d suggest using an RFC1918 range, but I think that means “not-Tailscale” (edit: see pshanew’s next comment). I haven’t investigated, but I wonder if Tailscale’s IPv6 (or native IPv6) would be a possibility.

13

My suggestion would be to use Tailscale’s subnet router feature. You can designate a particular Tailnet node on your network as a jump off point into your private network.

The other tailnet clients will route through that node to reach your server via the subnet router, at the server’s published private IP address.