Reverse Proxy Won't Start

[tomnjerry74 97]

Hello,

 

Sorry if this is off-topic for this section.

 

I've been trying to figure out nginx for hours and It just won't successfully bind to port 80. I ended up giving caddy a try and I'm just getting the same error.

 

If I change the port for the server (on either nginx or caddy) to, say, 8070 it successfully starts up but my emby server is inaccessible (the domain throws a basic security error in the browser).

 

Does anyone have any clue on how to either free up port 80 or get this to work at all? I have little to no experience in reverse proxies.

[Luke 42079]

What OS? Sounds like it's not getting permission to use port 80.

[tomnjerry74 97]

What OS? Sounds like it's not getting permission to use port 80.

 

I'm on Windows 10

[pwhodges 2012]

Is nginx/Caddy on the same machine as Emby?  Your message reads to me as if it is.  In that case, Emby must listen on different ports from those listened on by the proxy - on a given machine only one program can listen on each port.

 

Typically, the proxy would use 80/443 and forward to Emby on 8096.  If you then attempt to access Emby on 80/443, you will only get through if the proxy is working and set up right.  You can check or use Emby without the proxy by specifying the port 8096 in the call to it.

 

Paul

Edited February 7, 2020 by pwhodges

[tomnjerry74 97]

Is nginx/Caddy on the same machine as Emby?  Your message reads to me as if it is.  In that case, Emby must listen on different ports from those listened on by the proxy - on a given machine only one program can listen on each port.

 

Typically, the proxy would use 80/443 and forward to Emby on 8096.  If you then attempt to access Emby on 80/443, you will only get through if the proxy is working and set up right.  You can check or use Emby without the proxy by specifying the port 8096 in the call to it.

 

Paul

Paul thanks so much for the response

 

Yes, everything's on the same windows machine. I originally had my ssl set up in emby itself but was just trying to change over to the reverse proxy. Would you happen to know why it's not working if these are my settings?

 

caddy settings:

my.emby.server {
    proxy / 127.0.0.1:8096 
}

emby settings:

 

I'm just getting a little confused with all of the different port numbers. Are you saying I should change the emby ports at the bottom? If so, does it matter what they are?

[KMBanana 116]

You have it set correctly.  Public is what port devices should connect to to reach your server (so the reverse proxy ports).  Local is the ports emby actually is running on that the reverse proxy passes to.  

 

The most common reason why something can't bind to 80 is something is already using the port.  Could also be windows firewall interfering but I think the former is more likely your issue.  

[crusher11 1101]

What about port forwarding settings in the router?

[KMBanana 116]

The router should port forward to the reverse proxy, so 80 to 80 and 443 to 443 on your win10 machine where the reverse proxy is running.  

[crusher11 1101]

I'm not the OP, I was just offering another suggestion as to where things may have gone wrong.

[pwhodges 2012]

If you add the lines:

	log .\Logs\MBaccess.log
	errors .\Logs\MBerror.log

after the proxy line in the Caddy config, you will get logs (adjust the path used to your taste).  The access log will show you whether your requests are actually reaching Caddy, and what Caddy is able to do with them (a request to Caddy that fails when forwarded to Emby would show in the access log, not the error log).

 

The main Caddy process log (enabled by a -log parameter on the command line) will show you if Caddy has started without errors, has got its certificates in order, and so is running as expected.

 

Paul

[tomnjerry74 97]

If you add the lines:

	log .\Logs\MBaccess.log
	errors .\Logs\MBerror.log

after the proxy line in the Caddy config, you will get logs (adjust the path used to your taste).  The access log will show you whether your requests are actually reaching Caddy, and what Caddy is able to do with them (a request to Caddy that fails when forwarded to Emby would show in the access log, not the error log).

 

The main Caddy process log (enabled by a -log parameter on the command line) will show you if Caddy has started without errors, has got its certificates in order, and so is running as expected.

 

Paul

Okay this is what I'm getting now:

Activating privacy features... 2020/02/07 23:02:08 [INFO] [my.emby.server] acme: Obtaining bundled SAN certificate
2020/02/07 23:02:10 [INFO] [my.emby.server] acme: Obtaining bundled SAN certificate
2020/02/07 23:02:11 [INFO] [my.emby.server] acme: Obtaining bundled SAN certificate
2020/02/07 23:02:12 [INFO] [my.emby.server] acme: Obtaining bundled SAN certificate
2020/02/07 23:02:13 [INFO] [my.emby.server] acme: Obtaining bundled SAN certificate
2020/02/07 23:02:14 [INFO] [my.emby.server] acme: Obtaining bundled SAN certificate
2020/02/07 23:02:15 failed to obtain certificate: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLimited :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/, url:

[patsfan 1]

can someone help, i cant get the server connected online for the life of me, setup the ports in my router and still wont connect, i have plex going and it connects fine, just want to get emby up and running.

[Luke 42079]

can someone help, i cant get the server connected online for the life of me, setup the ports in my router and still wont connect, i have plex going and it connects fine, just want to get emby up and running.

 

Hi there, have you checked our our Connection Troubleshooter ?

[pwhodges 2012]

.

Edited February 8, 2020 by pwhodges

[pwhodges 2012]

 

OK, so Caddy is failing to get the required certificate, which is usually because Let's Encrypt is not able to get a response from port 80 to verify your address; and after several failures Let's Encrypt then prevents further attempts for a while.

 

The requirements for it to work are laid out in full here, and there is an alternative method of authenticating via your DNS provider for use in difficult circumstances (you have to download a copy of Caddy with the right client installed in that case, and configure the DNS challenge).  Note also the temporary setting for testing to get around the rate limit block.  If you need further help on Caddy specifically, the Caddy forums are responsive, so it might be best to ask there (I'm not around much this weekend).

 

Paul

 

PS: You do have a valid domain name there, I presume, and "my.emby.server" is a placeholder to hide it from the forum, right?

Edited February 8, 2020 by pwhodges

[tomnjerry74 97]

OK, so Caddy is failing to get the required certificate, which is usually because Let's Encrypt is not able to get a response from port 80 to verify your address; and after several failures Let's Encrypt then prevents further attempts for a while.

 

The requirements for it to work are laid out in full here, and there is an alternative method of authenticating via your DNS provider for use in difficult circumstances (you have to download a copy of Caddy with the right client installed in that case, and configure the DNS challenge).  Note also the temporary setting for testing to get around the rate limit block.  If you need further help on Caddy specifically, the Caddy forums are responsive, so it might be best to ask there (I'm not around much this weekend).

 

Paul

 

PS: You do have a valid domain name there, I presume, and "my.emby.server" is a placeholder to hide it from the forum, right?

Okay, so I've managed to set up caddy with the DNS plugin for namecheap (my provider), but now I just have to wait for namecheap to approve my API request so I can set it up for caddy use. I'll update when that's done.

 

 

And yeah, I was just using "my.emby.server" as a placeholder.

 

Thanks for all the help

[pwhodges 2012]

It occurred to me to check that you have actually opened port 80 through your router as well as 443.  It would be easy to think you only need 443 if you are using https, but Let's Encrypt uses 80 for the verification required to validate the certificate request.

 

Paul

[tomnjerry74 97]

It occurred to me to check that you have actually opened port 80 through your router as well as 443.  It would be easy to think you only need 443 if you are using https, but Let's Encrypt uses 80 for the verification required to validate the certificate request.

 

Paul

 

I double checked and my ports are open.

[patsfan 1]

Hi there, have you checked our our Connection Troubleshooter ?

tried with no luck. i will start a new post. sorry for hijacking previous post.

[jordy 284]

Have you set up a Dynamic DNS updater for your domain? I had the very same issue, traced it back to the Dynamic DNS setting in my domain config, it was incorrect due to my running a VPN at the time.

[tomnjerry74 97]

Have you set up a Dynamic DNS updater for your domain? I had the very same issue, traced it back to the Dynamic DNS setting in my domain config, it was incorrect due to my running a VPN at the time.

Yes, I do use dynamic DNS and I do use a VPN sometimes but I just double checked and it's still the correct IP. I still have access to emby remotely without the reverse proxy configured; I think if the IP was wrong that wouldn't be working too.

 

Appreciate the help

Edited February 9, 2020 by tomnjerry74

[jordy 284]

Yes, I do use dynamic DNS and I do use a VPN sometimes but I just double checked and it's still the correct IP. I still have access to emby remotely without the reverse proxy configured; I think if the IP was wrong that wouldn't be working too.

 

Appreciate the help

not necessarily. Depends on how you are accessing emby, if it's via your domain then yes it should be ok. But if you are going direct via your external IP then the settings in your domain config may still be wrong. Go to your domain page and check the dynamic IP, if it doesn't match your actual external IP then that is your problem. At least it was with mine anyway. good luck

[tomnjerry74 97]

It occurred to me to check that you have actually opened port 80 through your router as well as 443.  It would be easy to think you only need 443 if you are using https, but Let's Encrypt uses 80 for the verification required to validate the certificate request.

 

Paul

I have caddy up and running now and it says:

Serving HTTPS on port 443
https://my.domain.com


Serving HTTP on port 80
http://my.domain.com

However, when I try and access my site I'm greeted with a connection error.

 

 

 

I seriously just don't know what to do at this point. This is what my emby settings look like now, maybe something is wrong there?

 

 

My log file is also showing this now:

2020/02/10 17:23:28 [INFO] Caddy version: v1.0.4
2020/02/10 17:23:28 [INFO][cache:0xc0001bc0f0] Started certificate maintenance routine
2020/02/10 17:23:29 [INFO] Serving https://my.domain.com
2020/02/10 17:23:29 [INFO] Serving http://my.domain.com 
2020/02/10 17:26:42 http: TLS handshake error from [::1]:49998: no certificate available for 'fonts.googleapis.com'
2020/02/10 17:26:42 http: TLS handshake error from [::1]:49997: no certificate available for 'fonts.googleapis.com'
2020/02/10 17:32:31 http: TLS handshake error from [::1]:50160: no certificate available for 'fonts.googleapis.com'
2020/02/10 17:32:31 http: TLS handshake error from [::1]:50159: no certificate available for 'fonts.googleapis.com'

Edited February 11, 2020 by tomnjerry74

[pwhodges 2012]

I helped the OP sort this through PMs.  The issue was that the router was port-forwarding from 80/443 to the default Emby ports, and this forwarding had not been removed to enable those ports to go to the same ports in Caddy.  Once this was done, everything fell into place.

 

Paul

[Luke 42079]

That's great, thanks for doing that !