darkassassin07 423 Posted July 12, 2018 Share Posted July 12, 2018 (edited) When I am accessing my server through my reverse proxy with the android app I am receiving these requests approx every 10-15min <client IP here> [11/Jul/2018:21:05:48 -0700] "mydomain.com" "GET /embywebsocket?api_key=&deviceId= HTTP/1.1" 404 127 <client IP here> [11/Jul/2018:21:22:17 -0700] "mydomain.com" "GET /emby:443/emby/system/info/public HTTP/1.1" 404 127My WAN address as listed in the dashboard of my server is:Https://mydomain.com/emby:443 Nothing has stopped functioning, I'm just curious as to why the app is adding /emby:443 to the beginning of /emby/system/.... And not adding /emby to the websocket request. /edit <client IP here> [11/Jul/2018:21:22:17 -0700] "mudomain.co." "GET /emby/system/info/public HTTP/1.1" 200 198It looks like this request is being resent with the correct address once the initial request fails.The websocket one is not being re-requested with the correct address at all. Edited July 12, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
Luke 37049 Posted July 12, 2018 Share Posted July 12, 2018 Not sure but if you customized the wan address make sure that it is only the address and does not include any subfolders. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 12, 2018 Author Share Posted July 12, 2018 (edited) Emby is at the location /emby behind my reverse proxy. Thats why there is a subdirectory. Https://Mydomain.pw/emby/ proxies to http://<localip>/:8096 I have added a / to the very end to make https://mydimain.com/emby/:443 in the dashboard. Not sure if that will help or even matter but it couldn't hurt. This is still functioning just fine, all the rest of the requests are made to mydomain.com/emby/ as they should be its just these two that arent making it where they should /edit The added / didnt help, now '/emby/:443' is prepended to the request instead of '/emby:443' Edited July 12, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
Luke 37049 Posted July 12, 2018 Share Posted July 12, 2018 Ok, I wouldn't worry about it. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 12, 2018 Author Share Posted July 12, 2018 Im curious, what is the 'embywebsocket' request supposed to do? Its not at least somewhat important that it gets a 404 and is not re-requested with the proper uri? Link to comment Share on other sites More sharing options...
Luke 37049 Posted July 12, 2018 Share Posted July 12, 2018 It opens a web socket connection with the server. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 12, 2018 Author Share Posted July 12, 2018 (edited) I knew that much just from the name lol, I meant more what is that actually used for. I should have been more clear I guess. I could just add a location in nginx for that uri to redirect manually, but that seems like a workaround to a bug rather than an actual fix. Edited July 12, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
Luke 37049 Posted July 12, 2018 Share Posted July 12, 2018 It allows the server to send data to the apps in response to various events and actions that my have occurred. Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 12, 2018 Share Posted July 12, 2018 I knew that much just from the name lol, I meant more what is that actually used for. I should have been more clear I guess. I could just add a location in nginx for that uri to redirect manually, but that seems like a workaround to a bug rather than an actual fix. You shouldn't have to do anything special for websocket connections if your emby config, you probably have your timeout set to short and your ws connections are force disconnecting and being reopened until nginx forces them closed again. are you stripping off the /emby before it gets to your emby server? What does your config look like? Nginx config example: https://emby.media/community/index.php?/topic/48236-setting-up-emby-behind-a-reverse-proxy-nginx/?p=457670 Websocket timer settings: https://emby.media/community/index.php?/topic/48236-setting-up-emby-behind-a-reverse-proxy-nginx/?p=569575 Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 13, 2018 Author Share Posted July 13, 2018 (edited) I'll look at it a little closer and post my nginx config when I get home. Looking at my logs the only 'websocket' requests at all are exactly the same as the one posted above. The android app itself fails to prepend /emby/ to the request so it returns a 404 The app never attempts the correct uri. The /emby:443/emby/system/info request is re-requested with the correct uri everytime it gets the 404 as above Edited July 13, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 13, 2018 Share Posted July 13, 2018 I'll look at it a little closer and post my nginx config when I get home. Looking at my logs the only 'websocket' requests at all are exactly the same as the one posted above. The android app itself fails to prepend /emby/ to the request so it returns a 404 The app never attempts the correct uri. The /emby:443/emby/system/info request is re-requested with the correct uri everytime it gets the 404 as above oh i see what you are saying.. the logs are probably not entirely true, what do you have as your WAN address in emby? do you show the /emby there? if so remove it so it is just your domain.com Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 13, 2018 Author Share Posted July 13, 2018 (edited) If I do that emby apps will be making requests to https://mydomain.com/ and every single one will 404 It has to have the /emby/ or it wont make it to https://mydomain.com/emby/ as it should. As I have said it is only the websocket request that is being directed to the wrong place. Everything else is sent to https://mydomain.com/emby/<request here> exactly as it should be. I mean, I can try it once im home, but I really dont think that will do anything other than result in 404 for everything so noone using the apps can connect at all. Web app only. Edited July 13, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 13, 2018 Share Posted July 13, 2018 If I do that emby will be making requests to https://mydomain.com/ and every single one will 404 It has to have the /emby/ or it wont make it to https://mydomain.com/emby/ as it should. As I have said it is only the websocket request that is being directed to the wrong place. Everything else is sent to https://mydomain.com/emby/<request here> exactly as it should be. I mean, I can try it once im home, but I really dont think that will do anything other than result in 404 for everything so noone can connect at all. Lets check out your config first once you get home. I would depend more on your nginx logs if you keep them. look for the same entry, the emby logs are a little wonky when using a reverse proxy.. or pm me your domain name and i can probably see if its the app or the server. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 13, 2018 Author Share Posted July 13, 2018 I probably should have mentioned those are the nginx logs. Here is my NGINX config: Definitely looking for some input on it, curious how I have done given this is pretty new to me. Port 443 of mydomain.com is forwarded directly to this server. In emby: 'public https port number' = 443 'external domain' = mydomain.com/emby/ The remote access address on the dashboard is https://mydomain.com/emby/:443 (how can I make this not a link?) user www-data; worker_processes 4; pid /run/nginx.pid; include /etc/nginx/modules-enabled/*.conf; events { worker_connections 1024; } http { sendfile on; tcp_nopush on; tcp_nodelay on; types_hash_max_size 2048; server_tokens off; include /etc/nginx/mime.types; default_type application/octet-stream; log_format simple '$remote_addr [$time_local] "$host" "$request" $status $body_bytes_sent'; log_format verbose '$remote_addr [$remote_user][$time_local] "$host" "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for"'; error_log /<path>/error.log; access_log /<path>/main.access.log simple; # pretty heavy on the security mainly as a learning experience. Not something I have played with before this. ssl on; ssl_protocols TLSv1.2; ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA"; ssl_dhparam <file path>; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_buffer_size 32k; ssl_certificate <file path>; ssl_certificate_key <file path>; add_header X-Xss-Protection "1; mode=block" always; add_header X-Content-Type-Options "nosniff" always; proxy_hide_header X-Powered-By; add_header 'Referrer-Policy' 'no-referrer'; add_header Strict-Transport-Security "max-age=31536000" always; add_header Content-Security-Policy "frame-ancestors <host names>; default-src 'self'; script-src 'self'; img-src 'self'; style-src 'self'; font-src 'self'; object-src 'self'"; add_header Public-Key-Pins <redacted>; gzip on; gzip_disable "msie6"; gzip_comp_level 6; gzip_min_length 1100; gzip_buffers 16 8k; gzip_proxied any; gzip_types text/plain text/css text/js text/xml text/javascript application/javascript application/x-javascript application/json application/xml application/rss+xml image/svg+xml; server_names_hash_bucket_size 128; map_hash_bucket_size 64; client_body_timeout 10; client_header_timeout 10; keepalive_timeout 30; send_timeout 10; proxy_read_timeout 90; keepalive_requests 10; proxy_set_header HOST $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Range $http_range; proxy_set_header If-Range $http_if_range; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; server { server_name <mydomain.com>; listen 443 ssl default_server; listen [::]:443 ssl default_server; satisfy any; allow 192.168.0.0/24; auth_basic "Restricted"; auth_basic_user_file <file path>; deny all; #----------------- Error Handling --------------------- proxy_intercept_errors on; #I can't get this to work, with it uncommented anything that is not on the ip whitelist (ie the local network) gets a 401 without being asked to enter a password at all. #If I disable the ip whitelist and have basic_auth only it works just fine.... # error_page 401 /401.html; #401 = not authorized (not logged in) # location = /401.html { # allow all; # auth_basic off; # alias /usr/share/nginx/html/401.html; # access_log /<path>/unauth.access.log simple; # internal; # } error_page 404 /404.html; #404 = not found location = /404.html { auth_basic off; allow all; alias /usr/share/nginx/html/404.html; access_log /<path>/unrouted.access.log simple; internal; } error_page 500 502 503 504 /50x.html; #50X = server error location = /50x.html { auth_basic off; allow all; alias /usr/share/nginx/html/50x.html; access_log /<path>/httperror.log simple; internal; } #---------------- Misc ---------------------------- location = /Robots.txt {alias /etc/nginx/robots.txt;} location = /robots.txt {alias /etc/nginx/robots.txt;} #not sure if this is necessary for an https server location / { #unrouted/unknown request logging return 404; access_log /<path>/unrouted.access.log; } #--------------- Emby -------------------- location = / {return 301 https://$host/emby/;} #a re-direct for now. This will become something later. location /Items/ {return 301 https://$host/emby$uri?$args;} #these two are for the statistics plugin to load media images. location /web/ {return 301 https://$host/emby$uri?$args;} location /emby/ { auth_basic off; allow all; access_log /<path>/emby.access.log simple; client_max_body_size 20M; proxy_pass http://192.168.0.106:8096/; proxy_set_header Range $http_range; proxy_set_header If-Range $http_if_range; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } # irrelevant locations have been removed. } Here are the odd requests from the NGINX unrouted.access.log: [12/Jul/2018:22:31:32 -0700] "mydomain.com" "GET /embywebsocket?api_key=9ebc2f2e2eb946d19766a30f90636aaf&deviceId=d7afb2777c850f74 HTTP/1.1" 404 127 [12/Jul/2018:22:52:15 -0700] "mydomain.com" "GET /emby/:443/emby/system/info/public HTTP/1.1" 404 127The search term 'socket' does not exist in the emby.access.logThe /info request does show up in that log correctly as '/emby/system/info/public' just after the 404 with /emby/:443 Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 13, 2018 Author Share Posted July 13, 2018 (edited) I could add: location /embywebsocket { Return 301 https://$host/emby/embywebsocket?$args; }To manually redirect it, But thats a work around to what I think may be a bug. It would be better to fix the root cause (double post because editing a long post with code in it always screws me over) I also noticed I forgot to 'allow all; auth_basic off' for robots.txt while proof reading Edited July 13, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 13, 2018 Share Posted July 13, 2018 (edited) I probably should have mentioned those are the nginx logs. Here is my NGINX config: Definitely looking for some input on it, curious how I have done given this is pretty new to me. Port 443 of mydomain.com is forwarded directly to this server. In emby: 'public https port number' = 443 'external domain' = mydomain.com/emby/ The remote access address on the dashboard is https://mydomain.com/emby/:443 (how can I make this not a link?) Here are the odd requests from the NGINX unrouted.access.log: [12/Jul/2018:22:31:32 -0700] "mydomain.com" "GET /embywebsocket?api_key=9ebc2f2e2eb946d19766a30f90636aaf&deviceId=d7afb2777c850f74 HTTP/1.1" 404 127 [12/Jul/2018:22:52:15 -0700] "mydomain.com" "GET /emby/:443/emby/system/info/public HTTP/1.1" 404 127The search term 'socket' does not exist in the emby.access.logThe /info request does show up in that log correctly as '/emby/system/info/public' just after the 404 with /emby/:443 I would strip the /emby off of the requests going to emby... then start your "basic auth...." after the rewrite. This doesnt mean dont use domain.com/emby the rewrite will just strip that off the requests going to the emby server, making your RP more transparent and act as if there is no reverse proxy. I dont think the 301 redirect would work for you anyway. some of the android os's dont allow 301's within apps. location /emby/ { #note the backslash after emby rewrite ^/emby(/.*)$ $1 break; #this will strip /emby from the requests going into emby backend Edited July 13, 2018 by pir8radio Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 13, 2018 Author Share Posted July 13, 2018 (edited) Would you mind breaking down and explaining that rewrite command? I haven't messed with those yet, im not really sure how they work. However I don't believe that will change anything, every request that goes through the 'location /emby/' works exactly as it should already. The two requests that we are talking about are going through 'location /' where it is just logged to a different file and given a 404. If 301 wont work I could make a copy of the /emby/ location and change it to /embywebsocket. Then its just a proxy like the other one. I shouldn't have to though. The app should be requesting that correctly (adding /emby/) like it does for every other request, but it isnt. location / { #unrouted/unknown request logging return 404; access_log /<path>/unrouted.access.log; } Here are the odd requests from the NGINX unrouted.access.log Edited July 13, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 13, 2018 Author Share Posted July 13, 2018 (edited) I did give it a try: Added that, reloaded nginx, opened a web browser and connected to emby through nginx and I was given this screen: Nothing actually functions on this page and I had been automatically signed in the last time I connected before this This was an issue related to my contend security policy, not emby/nginx locations. adding the rewrite command didnt change anything. Edited July 13, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 13, 2018 Share Posted July 13, 2018 I think you are making things more difficult than they need to be.. /emby/ is only used on a handful of items in the emby server. ( i think branding, items, users, maybe a few others) by you using it in your path for nginx without stripping it off in the rewrite you are causing the emby items that actually need /emby to come up as /emby/emby/ and breaking your links. you can try my server I'll PM you my info.. See if that makes you feel more warm and fuzzy to send me yours.. I cant troubleshoot much more, its not an emby issue. its an nginx issue. The /emby strip should fix you up. look out for my PM. Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 13, 2018 Share Posted July 13, 2018 so to be clear, the strip code should be in and your wan address in emby server should NOT have /emby on it. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 14, 2018 Author Share Posted July 14, 2018 The /emby/ is already being stripped off the uri by the location itself. When nginx receives the request '/emby/emby/system/...' It passes '/emby/system/... ' to the emby server. I will send you my domain though. Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 14, 2018 Share Posted July 14, 2018 The /emby/ is already being stripped off the uri by the location itself. When nginx receives the request '/emby/emby/system/...' It passes '/emby/system/... ' to the emby server. I will send you my domain though. That's what I'm saying /emby/system is not a normal emby url. /system is though.. for example your home page probably looks like: https://domain.com/emby/web/index.html#!/home.html but the actual emby url is: https://domain.com/web/index.html#!/home.html /emby was added to cover old reverse proxy configs. So, you PM'ed me your url, and i noticed you send your base to /emby anyway... why even use /emby you don't need it? your redirects are whats screwing with android. If you MUST use domain.com/emby then we need to clean up your config a little.. But i would recommend you go with subdomains. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 14, 2018 Author Share Posted July 14, 2018 (edited) Im using sub domains to differ between the devices im connecting to, and locations to access the services through that particular device. I dont want to have several domains mainly because I'm using manual dns verification for my certs and Its a pain to have to deal with. location = / {return 301 https://$host/emby/;} #a re-direct for now. This will become something later. Edited July 14, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted July 14, 2018 Share Posted July 14, 2018 Im using sub domains to differ between the devices im connecting to, and locations to access the services through that particular device. I dont want to have several domains mainly because I'm using manual dns verification for my certs and Its a pain to have to deal with. That makes sense... wildcard certs are available but usually cost more. I also noticed all of the 301's in your config, you might find android sometimes does not obey those, I think its mostly from http to https though. Link to comment Share on other sites More sharing options...
darkassassin07 423 Posted July 14, 2018 Author Share Posted July 14, 2018 (edited) The vast majority of the requests to nginx are something like this: /emby/Sessions/Playing/Progress /emby/Audio/ /emby/Users/ Etc... They all have the /emby/stripped and /Sessions/Playing/progress Etc... Is passed to the emby server The /emby/emby/system path I searched for in the log, those above are just the bottom few lines of that log. @@pir8radio Do you have any idea why my 401 page wont work with auth_basic off and allow all? If I disable the ip whitelist it works just fine. Everyone is asked to auth and are given the 401 page if the fail/decline. If I leave the whitelist on and disable auth_basic (server wide) external ips get the 401 page and the internal ones arent asked to auth as you would expect. If both ip whitelist and auth_basic are enabled external ips are given a 401 without being asked to auth, and internal ones connect as normal. /edit Btw the 301s are for the statistics plugin to load images correctly through the web app. I didnt bother bring that up because the statistics plugin will become a separate server eventually. Excluding the 301 for '/', that's temporary until I setup a different server that will be located there. Nothing within the android app is routed through those at all. I have added a location to proxy '/embywebsocket' to emby manually and that is working. I knew I could do that from the beginning, I already had for the statistics plugin, but I was trying to get the devs to look into the app not sending that request the same way it does every other request. I appreciate your help @@pir8radio Edited July 14, 2018 by darkassassin07 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now