crusher11 851 Posted January 24, 2020 Author Share Posted January 24, 2020 What's the IP address associated with the 10053 errors? I've just had a look at the log and there were two errors in there 16 seconds apart with different IP addresses: 2020/01/25 02:43:50 [crit] 688#992: *2827 SSL_write() failed (10053: An established connection was aborted by the software in your host machine) while sending to client, client: xxx.yyy.zzz.fff, server: domain.com, request: 2020/01/25 02:44:06 [crit] 688#992: *2834 SSL_write() failed (10053: An established connection was aborted by the software in your host machine) while sending to client, client: xxx.yyy.zza.rrr, server: domain.com, request: I was the only one using the server at the time (and I should have been connected locally, too, so I have no idea why I'm showing up in the NGINX log at all). There's another one from like a minute earlier with an IP that's even more different, too. Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted January 24, 2020 Share Posted January 24, 2020 (edited) What's the IP address associated with the 10053 errors? I've just had a look at the log and there were two errors in there 16 seconds apart with different IP addresses: 2020/01/25 02:43:50 [crit] 688#992: *2827 SSL_write() failed (10053: An established connection was aborted by the software in your host machine) while sending to client, client: xxx.yyy.zzz.fff, server: domain.com, request: 2020/01/25 02:44:06 [crit] 688#992: *2834 SSL_write() failed (10053: An established connection was aborted by the software in your host machine) while sending to client, client: xxx.yyy.zza.rrr, server: domain.com, request: I was the only one using the server at the time (and I should have been connected locally, too, so I have no idea why I'm showing up in the NGINX log at all). There's another one from like a minute earlier with an IP that's even more different, too. Are the IP's external? stuff you do not recognize? Some of the apps will keep websockets open in the background.. maybe one of your phone or external tv apps? could also be just normal bad guys probing stuff... Edited January 24, 2020 by pir8radio Link to comment Share on other sites More sharing options...
crusher11 851 Posted January 24, 2020 Author Share Posted January 24, 2020 (edited) None of them are the IP returned by any of the "what's my IP" sites. I'm assuming my TV would have the same IP as my PC, right? EDIT: iplocation.net says they're all tied to CloudFlare. Edited January 24, 2020 by crusher11 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted January 24, 2020 Share Posted January 24, 2020 (edited) Ok so thats pretty normal, it might be one of your apps that have some open connections using your domain name. or could just be bad guys on the net hitting your domain name... Not out of the ordinary. The error is unusual... not necessarily the traffic. Edited January 24, 2020 by pir8radio Link to comment Share on other sites More sharing options...
crusher11 851 Posted January 24, 2020 Author Share Posted January 24, 2020 So are there troubleshooting steps to take regarding the 10053 errors? I have CloudFlare blocking all connections from outside Australia, which should cut bad traffic down pretty severely I'd imagine. As I asked before, is it possible to set things up so I can access via http://my.ip.address:port and troubleshoot any SSL issues that way? Skipping over the domain, NGINX, etc? Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted January 24, 2020 Share Posted January 24, 2020 So are there troubleshooting steps to take regarding the 10053 errors? I have CloudFlare blocking all connections from outside Australia, which should cut bad traffic down pretty severely I'd imagine. As I asked before, is it possible to set things up so I can access via http://my.ip.address:port and troubleshoot any SSL issues that way? Skipping over the domain, NGINX, etc? Yea you might already be able to reach IP:PORT can you not? To skip over nginx, you would just change the ports in emby to whatever you had working through cloudflare.. 443 and 80 probably. shut down nginx first so it is not listening on those ports too. Link to comment Share on other sites More sharing options...
crusher11 851 Posted January 25, 2020 Author Share Posted January 25, 2020 It just times out if I try to access via my IP. The ports in emby already are 443 and 80. Weirdly if I go to my.ip:80, it only shows my.ip in the address bar. If I try ports 8920, 8096 or 443, the port displays in the address bar. It times out on all of them though. Link to comment Share on other sites More sharing options...
crusher11 851 Posted January 27, 2020 Author Share Posted January 27, 2020 @@pir8radio any idea why I can't access via IP? Link to comment Share on other sites More sharing options...
crusher11 851 Posted January 28, 2020 Author Share Posted January 28, 2020 I'm no longer able to log in when accessing via domain either. I get an 'invalid username/password' error. Could this be related to something I've changed in NGINX/Cloudflare/Emby? Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted January 29, 2020 Share Posted January 29, 2020 no, can you get in locally? from your network or on the actual emby server? Link to comment Share on other sites More sharing options...
crusher11 851 Posted January 29, 2020 Author Share Posted January 29, 2020 Yes. Link to comment Share on other sites More sharing options...
crusher11 851 Posted January 30, 2020 Author Share Posted January 30, 2020 Okay, that turned out to be the NGINX issue discussed in the Testing Area. I still can't access via IP:PORT, even with NGINX turned off and your NGINX config in place, though. Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted January 30, 2020 Share Posted January 30, 2020 Okay, that turned out to be the NGINX issue discussed in the Testing Area. I still can't access via IP:PORT, even with NGINX turned off and your NGINX config in place, though. so, you shut of nginx, then go into emby and change the http port to whatever your nginx was listening on (im guessing 80) restart emby, and you cant go to INTERNETIP:PORT and reach emby directly? Is is a docker container or something? I forgot what you said. Link to comment Share on other sites More sharing options...
crusher11 851 Posted January 31, 2020 Author Share Posted January 31, 2020 The http port in emby is already the port NGINX was listening on, so I don't need to change it, but otherwise that's correct. I don't know what a docker container is. Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted January 31, 2020 Share Posted January 31, 2020 The http port in emby is already the port NGINX was listening on, so I don't need to change it, but otherwise that's correct. I don't know what a docker container is. That may be why you can not access it directly... those should be different if emby and nginx are on the same computer. Link to comment Share on other sites More sharing options...
crusher11 851 Posted February 1, 2020 Author Share Posted February 1, 2020 Why? And would it make a difference given that I'm turning NGINX off when trying to access directly? You're saying to change the port in emby to match the NGINX port when turning NGINX off anyway, so I'm ending up in the same place. Link to comment Share on other sites More sharing options...
Luke 37060 Posted February 1, 2020 Share Posted February 1, 2020 You shouldn't try to run two apps at the same time bound to the same port. Link to comment Share on other sites More sharing options...
crusher11 851 Posted February 1, 2020 Author Share Posted February 1, 2020 It's been running just fine so far. @@pir8radio is suggesting turning off NGINX and changing emby's port to match the NGINX port, but if the two ports are the same then simply turning off NGINX gets me to that point anyway. The issue must be elsewhere. How do I pick a different port for emby? It's on 80 for http and 443 for https, as is NGINX. Link to comment Share on other sites More sharing options...
Luke 37060 Posted February 1, 2020 Share Posted February 1, 2020 You've just been getting lucky, that's why it's been running. Link to comment Share on other sites More sharing options...
crusher11 851 Posted February 1, 2020 Author Share Posted February 1, 2020 Hmm. Might be a "stopping NGINX" issue...there are currently 9 instances of NGINX running at the moment. What's the story here? Link to comment Share on other sites More sharing options...
Luke 37060 Posted February 1, 2020 Share Posted February 1, 2020 I can't really answer that as it's specific to your personal environment. Link to comment Share on other sites More sharing options...
crusher11 851 Posted February 1, 2020 Author Share Posted February 1, 2020 And how do I go about picking different ports for emby? I assume I need to change both 443 and 80? I have no idea what the valid options are or what ports might be in use. Link to comment Share on other sites More sharing options...
Luke 37060 Posted February 1, 2020 Share Posted February 1, 2020 You were able to change the default local ports in emby server before so simply go back to the same place and change them back, in the server network settings. Defaults are 8096 and 8920. Link to comment Share on other sites More sharing options...
crusher11 851 Posted February 1, 2020 Author Share Posted February 1, 2020 (edited) I know where to enter the numbers, I'm concerned about picking the correct ones. It's currently 8096 for local http and 8920 for local https. 80 and 443 as the public http and https ports. Which leads me to ask...has this whole sidebar been a misunderstanding about whether @@pir8radio meant the local or the public ports? Or are the public and local ports supposed to match? Or what's the story? Also I tried killing NGINX and it killed all nine instances, so that works. Not sure why there were nine of them to begin with though? Edited February 1, 2020 by crusher11 Link to comment Share on other sites More sharing options...
pir8radio 1292 Posted February 1, 2020 Share Posted February 1, 2020 (edited) Hmm. Might be a "stopping NGINX" issue...there are currently 9 instances of NGINX running at the moment. What's the story here? That's normal the line in your nginx config "worker_processes auto; " (can also be a number instead of auto) Its usually based on how many cpu cores you have. See here is mine: You can also create an nginx short cut, then edit that shortcut to look like the below image... Then when you run that shortcut, it will "restart" nginx, usually not dropping any live streams. Good way to update your config without dropping production connections. You can create another shortcut just change reload to stop and it will kill nginx gracefully. Edited February 1, 2020 by pir8radio 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