I’m not understanding what this means? Can you explain a bit more?
It is exactly as you say. When I configure IPv6 and IPv4 in the (PMS) network settings, the Remote Access page only offers me an IPv4 address for configuration! Only the Samsung TV get confused.
Is this related to enabling IPv6 only or Dual Stack or just the build in general?
I use Dual Stack!
What is dashboard showing when you’re playing from this TV on your local network? Can you test this can capture your PMS logs?
I’ve already written a post about this, but I haven’t found it yet. I have log files, including TV logs. I’ll send them to you via PM. If you tell me your PM..
Found it. We can carry on in your thread here: PlexMediaServer-1.43.3.10768 and Samsung-TV is a NoGo!
Please help. How can I send it to you. II get a “Not allowdet”.
A second Mail seams to be ok???
@Atomatth is this beta expected to support getting the true client IP when Plex is behind an IPv6 reverse proxy? I’m seeing the IPv6 address of the reverse proxy as the source when streaming in Plex 
For some extra info, I have a static /48 IPv6 lease from my ISP, and I have both a reverse proxy (Envoy Gateway) and Plex running with separate IPv6 IPs from this lease. The Envoy proxy is correctly sending x-forwarded-for, x-real-ip and x-forwarded-proto headers to Plex, and in Plex’s network settings I have my entire /48 set as a “LAN Network” and “List of IP addresses and networks that are allowed without auth”. Looking at the verbose logs, I can see VERBOSE - X-Forwarded-For: <my-ipv6-block>:40::15f0 (which is my desktop’s IPv6 address) but I see other logs like:
DEBUG - Request: [[<my-ipv6-block>:6901::6633]:56846 (WAN)] GET /:/prefs (36 live) #432 GZIP Signed-in Token (duckworld1) / accept => application/xml / accept-encoding => gzip, deflate, br, zstd / accept-language => en-GB / cookie => AUTHP_SESSION_ID=<snip> / host => plex.<my-domain> / priority => u=1, i / referer => https://plex.<my-domain>/web/index.html / sec-ch-ua => "Google Chrome";v="149", "Chromium";v="149", "Not)A;Brand";v="24" / sec-ch-ua-mobile => ?0 / sec-ch-ua-platform => "Linux" / sec-fetch-dest => empty / sec-fetch-mode => cors / sec-fetch-site => same-origin / user-agent => Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36 / x-envoy-external-address => <my-ipv6-block>:40::15f0 / x-forwarded-for => <my-ipv6-block>:40::15f0 / x-forwarded-proto => https / X-Plex-Client-Identifier => l18gqdb5v3fipwl9orasrjd0 / X-Plex-Device => Linux / X-Plex-Device-Name => Chrome / X-Plex-Device-Screen-Resolution => 2560x1405,2560x1440 / X-Plex-Features => external-media,indirect-media,hub-style-list / X-Plex-Language => en-GB / X-Plex-Model => bundled / X-Plex-Platform => Chrome / X-Plex-Platform-Version => 149.0 / X-Plex-Product => Plex Web / X-Plex-Session-Id => c9e342b4-f77b-435f-8a72-d6aefb1923d8 / X-Plex-Token => xxxxxxxxxxxxxxxxxxxx / X-Plex-Version => 4.159.0 / x-real-ip => <my-ipv6-block>:40::15f0 / x-request-id => aba0f8dc-b765-4dc4-a633-8e9fa2b5ad20 / x-requested-with => XMLHttpRequest
([<my-ipv6-block>:6901::6633 is the Envoy Gateway proxy).
I’d really love to see Plex support this!
Just curious what happens here if you remove these values. Regardless thanks for reporting. I’ll pass it along.
With those values unset, Plex now thinks the connection is remote:
…which makes sense, as all these addresses are GUA (i.e. public) and Plex can’t possibly know how big my subnet/LAN is.
Looking at the Plex logs, I am seeing the same behaviour - there are logs saying VERBOSE - X-Forwarded-For: <my-ipv6-block>:40::15f0 but the actual DEBUG - Request logs still show the Envoy Gateway IP.
Appreciate you passing this along; happy to do any more tests / provide more logs if needed! 
I am happy to report a good exprience configuring and running Plex Media Server and Plex clients for IPv4, IPv6 and IPv4/IPv6 (dual-stack) networks.
Plex Media Server version 1.43.3.10793 (Plex Pass)
Docker Container: Plexinc/pms-docker
Platform: Unraid 7.3.1
The usual router IPv4 port-forwarding configuration (public IPv4 address:port forwarding to a private IPv4 address:port) is required when hosting Plex Media Server on a host with a private IPv4 address. All fine – as expected.
When Plex server and Plex client have IPv4 and IPv6 addresses Plex Media Server and Plex client communicate using IPv4. If I disable IPv4 on the client (I simply turned off IPv4 on iMac network interfaces) communication between Plex Media Server and Plex clients happens via IPv6 (IPv6 public addresses). All fine - as expected.
Plex on AppleTV seems happy to communicate with Plex Media Server using IPv4 or IPv6.
I think I noticed Plex Dash web reporting when Plex client using IPv6. I didn’t check Plex Dash for iOS to see if it reports IPv6 Plex client address.
I noticed Tautulli produced an error when a Plex client uses IPv6. This isn’t a suprise. If we are lucky Tautulli will receive a future update to resolve this (Tautulli… very well maintained! Tautulli, an excellent Plex Media Server companion!).
When running Plex Media Server “IPv4 Only” I had defined one “Custom server access URLs”. With Plex Media Server “IPv4 Only” this worked fine - as expected.
I am yet to explore how “Custom server access URLs” functions with Plex Media Server configured IPv6 Only or IPv4 and IPv6 (dual-stack). This is something I’m looking forward to checking out over the next few days.
I’m very happy for the improved support for IPv4 and IPv6 networks. Thanks Plex inc!
I’m a bit confused here, I’ve been using Plex over IPv6 for many years (and I’ve troubleshooted many times in the past the API responses, to confirm that the correct x.plex.direct IPv6 hostname was advertised to clients, and I’m using a custom url with a IPv6-only hostname), what has changed recently?
The /56 boundary seems logical to separate local from remote GUA traffic: few residential connections get bigger subnets than that. ULA and link-local traffic is also by definition local.
