Reverse proxy : no error but domain not loading?

1. Caddy version (caddy version):

v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

2. How I run Caddy:

I run caddy wih a reverse proxy, from a domain name example.duck.dns to Jellyfin on port 8096 on my local computer.

a. System environment:

Windows 10, 64 bits

b. Command:

caddy run

c. Service/unit/compose file:

paste full file contents here

d. My complete Caddyfile or JSON config:

example.duckdns.org {
    encode gzip
        log {
            output file C:\caddy\logs\jellyfin_access.log {
                roll true               # Rotate logs, enabled by default
                roll_size_mb 5          # Set max size 5 MB
                roll_gzip true          # Whether to compress rolled files
                roll_local_time true    # Use localhost time
                roll_keep 2             # Keep at most 2 log files
                roll_keep_days 7        # Keep log files for 7 days
            }
        }
    reverse_proxy localhost:8096
}

3. The problem I’m having:

Running Caddy seems ok (see terminal ouput below) but when going to example.duckdns.org, nothing loads. When doing a curl example.duckdns.org I receive curl: (52) Empty reply from server

4. Error messages and/or full log output:

2020/07/23 08:15:54.913 e[34mINFOe[0m using adjacent Caddyfile 2020/07/23 08:15:54.916 e[34mINFOe[0m admin admin endpoint started {“address”: “tcp/localhost:2019”, “enforce_origin”: false, “origins”: [“localhost:2019”, “[::1]:2019”, “127.0.0.1:2019”]} 2020/07/23 08:15:54.917 e[34mINFOe[0m http server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {“server_name”: “srv0”, “https_port”: 443} 2020/07/23 08:15:54.917 e[34mINFOe[0m http enabling automatic HTTP->HTTPS redirects {“server_name”: “srv0”} 2020/07/23 08:15:54.929 e[34mINFOe[0m tls cleaned up storage units 2020/07/23 08:15:54.929 e[34mINFOe[0m http enabling automatic TLS certificate management {“domains”: [“example.duckdns.org”]} 2020/07/23 08:15:54.946 e[34mINFOe[0m autosaved config {“file”: “C:\Users\PA\AppData\Roaming\Caddy\autosave.json”} 2020/07/23 08:15:54.946 e[34mINFOe[0m serving initial configuration 2020/07/23 10:15:54 [INFO][cache:0xc0002a1f80] Started certificate maintenance routine

5. What I already tried:

Well I tried this with a local port and it works fine. Maybe it has something to do with my ISP ? However I took care of forwarding port 80 to 80 and port 443 to 443 in my router settings (NAT/PAT settings).

6. Links to relevant resources:

I followed this tutorial : Caddy | Documentation - Jellyfin Project

Hey @peehay,

I’m less inclined to suspect Caddy is playing foul here as more likely this is a networking/routing issue, but lets just confirm first that a proper connection to Caddy actually does get a good response.

Could you run this and post the output (replacing CADDY_IP with the local IP address of your Caddy host server, and example.com with your domain name):

curl -I https://example.com --resolve example.com:443:CADDY_IP

Hi Whitestrake,
thanks for helping me. So the output of

curl -I https://example.duckdns.org --resolve example.duckdns.org:443:CADDY_IP 

is

HTTP/1.1 302 Found
Date: Fri, 24 Jul 2020 07:53:44 GMT
Location: /web/index.html
Server: Caddy
Server: Kestrel

Trying to solve the problem on my own, I changed my Caddyfile to proxy to reverse_proxy /jellyfin/* CADDY_IP:8096 instead of reverse_proxy CADDY_IP:8096 (while changing the settings on Jellyfin), and the command

curl -I https://example.duckdns.org --resolve example.duckdns.org:443:CADDY_IP

gives me this time

HTTP/1.1 200 OK
Server: Caddy
Date: Fri, 24 Jul 2020 10:09:24 GMT 

Might be useful, but it doesn’t help me alone

Edit : However I might add that this doesn’t solve my problem, going to example.duckdns.org still gives me nothing

So, the HTTP/1.1 302 Found from Server: Kestrel is good!

It means that when you send the request directly to Caddy, and ask for your site, Caddy is reverse proxying it and you’re getting a good response.

You shouldn’t need to change the reverse_proxy from what you had when you got this response, it’s working at this stage.

The problem appears to be when we use external DNS to find your site. That means this issue is either DNS or networking.

Try running nslookup example.duckdns.org and confirm that it’s your public IP address. If it’s not, DNS is your problem.

If it is the correct IP address, try pulling out your phone and navigating to your site with Wi-Fi off (i.e. access your website from the internet, not from LAN).

If it works on your phone, we can infer that the issue is likely (lack of) hairpin NAT.

If it fails on your phone, we can infer that the issue is likely port forwarding.

This topic was automatically closed after 30 days. New replies are no longer allowed.