Im getting 502 Bad gateway errors with proxy


(Yami) #1

Hello, I am getting 502 errors when accessing trying to access my server:

Im using dynamic DNS from a google domain I own, all of them (domain and subdomains) are pointing correctly to my IP.

Now, I want to be able to access some of my internal services from outside my network with something like xxx.domain.com, using https.

https://xxx.domain.com {
     proxy / someinternal.ip
 }

Is what Im doing in my Caddyfile, but when I try to access it from a browser I get a “502 Bad gateway” error.
This is happening with everything I try to proxy

I researched a bit bit didnt really find a cause or solution that works for me. Internally, these services do work thru https.

I dont get any error in the command output and the log doesnt seem to show anything else.


(Matthew Fay) #2

When you proxy to someinternal.ip, there’s an implicit scheme and port, so Caddy will be trying to connect to http://someinternal.ip:80/. If it’s actually available over HTTPS, you’ll want to specify https://someinternal.ip:port/.

Now, if you’re using HTTPS for an IP address internally, it’s not publicly validated. That means Caddy won’t connect unless you tell it, explicitly, to skip verification of the upstream certificate. To do that, you want to use the insecure_skip_verify subdirective for proxy.

https://caddyserver.com/docs/proxy


(Yami) #3

Cool! Its working, when writing the post I forgot to actually write the whole https://internal.ip, I do have them written like that in my Caddyfile, but I did not have the insecure_skip_verify part.

insecure_skip_verify overrides verification of the backend TLS certificate, essentially disabling security features over HTTPS.

Does this mean that im not getting benefits from https? Or is it just discarding the original one from the server and instead using Caddy’s?


(Matthew Fay) #4

There’s two benefits to certificate-based HTTPS: Encryption and external validation/trust.

External validation is important because it verifies the server you’re talking to is the server you want to be talking to, and not someone else or an opportunistic middleman. The encryption still works, you just can’t trust that your messages are being encrypted to the right target.

This is all much less of an issue in a controlled private internet. Yes, you’re not getting the full benefits of HTTPS - but in my opinion, your network is either secure enough for you to use regular HTTP (and avoid the albeit small overhead of HTTPS entirely), or it’s insecure and you should generate and distribute your own certificate authority to the computers that need to communicate securely.


(Yami) #5

I see, encryption is what I cared the most and i still would have it, so its cool

Thank you so much for you help! :slight_smile: