Server Version#: 1.17.0.1841
Player Version#: 3.108.2 (web client)
Here is my issue, my ISP is double Nat’ing me. They did finally set up my internal IP with a port forward for 32400 to my IP, I then port forwarded that to my server. It took them 2 years to open the port… so I really don’t want to go back through them again. So at the moment I only have 1 Public IP, that is limited to a specific port. (I can not use 2 different ports, they will all have to be under the same ip/port)
I’ve been itching to be able to get other web apps through my terrible internet provider, so I can access stuff externally, so I recently setup and configured an NginX reverse proxy that is looking for specific sub domains and redirecting to the correct port internally.
When I set this up, I can now access Plex in a web interface, along with any/all other applications I need so I was very excited. Until I opened up my Plex phone app and it can’t connect anymore. Reading online it appears I have to have an entire port open specifically Plex without a reverse proxy in between it, as its calling out to direct.plex URL’s?
So my question is… is it even possibly to user a reverse proxy with a custom URL and have it directly connect to my server for remote access? It seams like plex doesn’t care about DNS names, and only looks at my public IP (*Which remember is “our” public IP, as I get to share it with who knows how many other customers).
Thank you, I did see that and it is set. Is there any info on troubleshooting this further?
Also I did try using my own custom cert on Plex (added the pfx etc…) but I don’t believe it is needed, as nginx is handling the SSL portion, it is also set to “preferred” while testing things out.
Disclaimer, nginx hands out the cert fine and I don’t get any errors scanning externally or hitting it. SO I don’t believe it is SSL related.
I also run Nginx and forward a bunch of sites on port 443 but I do not have Plex setup in Nginx as I ran into issues with it like you are having.
Plex for remote access uses a URL like below which uses a cert generated by Plex unique to your external IP which gets tied back in the Plex “cloud” that makes things work seamlessly.
When you use Nginx you dont have that “plex.direct” cert loaded which probably beaks remote access.
Maybe someone else can chime in and provide some insight but I do not believe it is possible to forward Plex using Nginx and use remote access.
I was thinking I may be able to proxy forward any plex.direct streams to my server as well. That way it passes through, however it really shouldn’t need to use the plex.direct links at all, since I have my own domain forwarded and SSL is valid. I would love to get more info on this and test things out. The server logs are not showing very useful information.
If you’re using something like docker, then look into jwilder/nginx-proxy + jrcs/letsencrypt-nginx-proxy-companion … is an easy solution because it creates nginx config / certs automatically for every other container
and it is very possible (as it it works 100% of the time) to forward plex using Nginx and use remote access
I’m already using something similiar to automate SSL and configs. It is %100 accessible from off my network if I hit my domain:port.
My issue is that plex.tv is not seeing it… so though my web browser is working great, when I open my Plex iphone app, it fails to see it… since “remote access” can’t be used.
If i change my port forward rule in my router to point directly to my PMS Docker container, it works great, if I point it to NginX, which direct it to Plex it ruins it.
I did not have any of these environment variables so I added them and gave it a restart. Doesn’t appear to have helped. Here is my docker-compose plex portion:
plex:
container_name: plex
image: linuxserver/plex:latest
restart: unless-stopped
devices:
- /dev/dri:/dev/dri # For hardware acceleration
environment:
- ADVERTISE_IP=https://plex.mydomain.com:32400/
- PLEX_CLAIM=claim-<claim code>
- TZ=${TZ} # timezone, defined in .env
- PUID=${PUID} # default user id, defined in .env
- PGID=${PGID} # default group id, defined in .env
- VIRTUAL_HOST=plex.<domain.com>
- VIRTUAL_PORT=32400
- VIRTUAL_NETWORK=nginx-proxy
volumes:
- ${ROOT}/plex/config/:/config # plex database
- ${ROOT}/plex/transcode:/transcode # temp transcoded files
- ${MEDIA}:/data # media library
- ${CERT}:/cert
ports:
- 32400:32400/tcp
- 3005:3005/tcp
- 8324:8324/tcp
- 32469:32469/tcp
- 1900:1900/udp
- 32410:32410/udp
- 32412:32412/udp
- 32413:32413/udp
- 32414:32414/udp
networks:
- media
- proxy
My domain name points to my public IP, but if the port is not specified there it will not route properly through to me (since I’m double nat). Is that going to be an issue?
Also sounds like you have tested this before, can you confirm that you have got a reverse proxy with plex.tv remote access both working?
yes, I have plex behind an nginx reverse-proxy and remote access works great, it has to as my box is remote to me 100% of the time. It’s in a datacenter
I haven’t set it up behind a consumer router in a very long time, but you are probably missing pieces in your nginx YML as well.
Which is why I reference the jwilder/nginx-proxy stuff.
Thank you for confirming, everything I read online was years ago so I wasn’t positive.
I would love to host externally, however I can’t. My internet download speeds are only 35mbps, and I have recently started doing 4K/HDR content. It would be extremely hard to do that. I also just upgrade my server and already have 24tb of storage, so my up front cost is already done.
I do not believe it is my router configs, so my ISP port forwards publicip:32400 to my staticip:32400.
I then port forward 32400 to my server on 32400 (for plex directly) and it works great.
I can also port forward to 443 (for nginx) and it breaks everything… but all my proxy stuff works and its still available externally, just not plex.tv remote access.
That leaves us down to either a plex configuration issue, or an nginx issue. I used the linuxserver lets encrypt image, that has built in nginx and cerbot for ssl etc…
IDK I messed with this for the last couple hours with no success.
I can setup the PFX and get to https://plex.mydomain.com with no errors
Once I tell Plex remote access to use port 443 instead of 32400 it just shows Not Available Outside
Ill keep jacking with this and see if I get any success.
BTW I am using linux server dockers for both Plex and Letsencrypt.
Yes I have got the PFX to work as well, it didn’t seam to change anything. I believe I’m going to have to have 2 ports open to do this, 1 for a direct connection to my server (no reverese proxy) and another for my proxy.
Seams weird that it can’t directly connect through the proxy though. I’m down at Splunk Conf, so I have not had any time to play with it more, but next week I’ll for sure be back at it, hopefully can figure out a solution, been think of some things to test
Also, I’m using linuxserverio images (both for plex and letsencrypt)
So I believe I got this working just fine. My issue was that I can’t test from my work VPN or from my internal network… so if I hotspot to my phone it works fine. Kind of weird rules internally and through work.
Anyways, this is my config files, I did it with sub domains plex.domain.com instead of the domain.com/plex at the end etc… but both ways are possible.
In addition to this, I have .env variables set for all the PUID/PGID/TZ and ROOT.
So in my nginx folder above, there is another folder called nginx, and then a site-confs. Simply create a plex.conf tile, and this is my plex conf file. I have others as well. I left the default file as well, but emptied the file so that it didn’t set stuff I didn’t want.
/nginx/nginx/site-confs
upstream plex {
server plex:32400; #note i simply used "plex" since it is the containers name, and it is on the same network as nginx so it can simply use this. If not you can use the IP address.
}
server {
listen 80;
server_name <plex.yourdomain.com>;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2 default_server;
server_name plex.<yourdomain.com>;
send_timeout 100m; #Some players don't reopen a socket and playback stops totally instead of resuming after an extended pause (e.g. Chrome)
ssl_certificate /config/etc/letsencrypt/live/<yourdomain>.com/cert.pem;
ssl_certificate_key /config/etc/letsencrypt/live/<yourdomain>.com/privkey.pem;
ssl_trusted_certificate /config/etc/letsencrypt/live/<yourdomain>.com/chain.pem;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-#SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GC#M-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA#-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SH#A384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-A#ES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA#-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AE#S256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:D#ES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-S#HA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_stapling on;
ssl_stapling_verify on;
ssl_session_tickets on;
access_log /config/log/nginx/<yourdomain>.com.access.log;
error_log /config/log/nginx/<yourdomain>.com.error.log;
gzip on;
gzip_vary on;
gzip_min_length 1000;
gzip_proxied any;
gzip_types text/plain text/css text/xml application/xml text/javascript application/x-javascript image/svg+xml;
gzip_disable "MSIE [1-6]\.";
client_max_body_size 100M;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Accept-Encoding "";
proxy_redirect off;
proxy_buffering off;
location / {
proxy_pass https://plex;
}
}
I tried breaking apart both nginx and letsencrypt portions, and ran into a lot of headache… this image combines them both into 1 and it makes it much easier to setup IMO.
