Caddy Setup Issue - Address already in use

Troilus98 · November 6, 2021, 2:47am

1. Caddy version (`caddy version`):

2.4.5

2. How I run Caddy:

a. System environment:

Windows 11 - Docker 4.1.1

b. Command:

Caddy run

or just click start in Docker

c. Service/unit/compose file:

version: "3.7"

services:
  caddy:
    image: caddy:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - caddy_data:/data
      - caddy_config:/config
      - C:\Caddy\Caddyfile:/etc/caddy/Caddyfile

volumes:
  caddy_data:
  caddy_config:

d. My complete Caddyfile or JSON config:

komga.troilus98.com {
	reverse_proxy http://localhost:8080	
}

3. The problem I’m having:

My end goal is to be able to access a page hosted locally at localhost:8080 over the internet. I have a google domain and it is configured properly pointing at my ip. I have attempted following all the guides I can find, but do not understand what step I am missing to make caddy work as the intermediary.

I have tried starting the Caddy tutorial to try and learn more to fix my own issue, but I can not get past the first step. (The tutorial at https://caddyserver.com/docs/getting-started.) (I tried installing Caddy as a windows service months ago when I was able to get further into the tutorial, but with Caddy running in docker there seems to be a block to allow the most basic access that I don’t have enabled.) I’m quite new to these types of configs, so I’m stumbling my way through.

4. Error messages and/or full log output:

Running Caddy inside Docker, caddy command lines will not work in windows Powershell, so I run caddy commands through the Terminal that pops up when I click “CLI” in Docker. If I try Caddy run, I get this error:

/srv # caddy run
run: loading initial config: loading new config: starting caddy administration endpoint: listen tcp 127.0.0.1:2019: bind: address already in use

If I try testing the server via the 3rd command in the tutorial using curl, I get this error:

PS C:\> curl localhost:2019
curl: (7) Failed to connect to localhost port 2019: Connection refused

PS C:\> curl -v localhost:2019
* Rebuilt URL to: localhost:2019/
*   Trying ::1...
* TCP_NODELAY set
*   Trying 127.0.0.1...
* TCP_NODELAY set
* connect to ::1 port 2019 failed: Connection refused
* connect to 127.0.0.1 port 2019 failed: Connection refused
* Failed to connect to localhost port 2019: Connection refused
* Closing connection 0
curl: (7) Failed to connect to localhost port 2019: Connection refused

I’ve tried testing “curl localhost:8080” and I do receive output from the page I have running there.

5. What I already tried:

I looked at a few of the other posts on here about address already in use, but could not find a fix. I tried a netstat command I saw suggested in one of them to see if that port was in use, but did not see anything running on port 2019.

PS C:\Users\ikerz\OneDrive\Desktop> netstat

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    127.0.0.1:9012         mc:49706               ESTABLISHED
  TCP    127.0.0.1:9487         mc:49687               ESTABLISHED
  TCP    127.0.0.1:31111        mc:50311               ESTABLISHED
  TCP    127.0.0.1:49670        mc:49935               ESTABLISHED

6. Links to relevant resources:

francislavoie · November 6, 2021, 4:27am

Troilus98:

Running Caddy inside Docker, caddy command lines will not work in windows Powershell, so I run caddy commands through the Terminal that pops up when I click “CLI” in Docker. If I try Caddy run, I get this error:
/srv # caddy run
run: loading initial config: loading new config: starting caddy administration endpoint: listen tcp 127.0.0.1:2019: bind: address already in use

That’s because Caddy is already running in the container. You don’t need to run it again!

The instance of Caddy that started with the container is already bound to port 2019, so you can’t bind to it again by running Caddy a second time.

Troilus98:

If I try testing the server via the 3rd command in the tutorial using curl, I get this error:
PS C:\> curl localhost:2019
curl: (7) Failed to connect to localhost port 2019: Connection refused

That’s because Caddy is listening on localhost:2019 which you can only access from inside the container, by default.

The getting started guide assumes you’re running Caddy directly on your host machine, not in Docker. Running in Docker complicates things because there’s a layer of isolation between your host machine and Caddy.

You’re reverse proxying to localhost here. When running in Docker, localhost means “this container”, it doesn’t mean “this physical computer”.

Where is the service running? Is it running directly on your Windows environment, or is it also running in Docker?

If it’s in Docker, then make sure your Caddy container is in the same Docker network as your other service, then use the other service’s name as the address. Say the service/container name is otherservice, you’d do reverse_proxy otherservice:8080

If it’s running on Windows, then… it’s a bit more complicated. I’d probably recommend just running the native Windows version of Caddy instead.

Troilus98 · November 7, 2021, 7:33pm

Thanks for the reply.

That’s what I assumed, but I could never ‘see’ it running. In the CLI that docker allows me to popup on Caddy, I can’t use curl inside there, so I’m not sure how to check it that way.

So what confuses me about this statement is that I have Komga running a server in a Docker container, but I can access it via localhost:8080 in a web browser outside of the container. So it seems like conflicts to me about what can and can’t be accessed in/outside container terminals. For reference the Komga container was setup via command line with:

 docker create --name=komga --user 1000:1000 -p 8080:8080 --mount type=bind,source=C:\Komga\config,target=/config --mount type=bind,source=D:\-=_Comics_=-,target=/data   --restart unless-stopped gotson/komga

So I tried changing my caddy file so it read “reverse_proxy http://komga:8080”, but when trying to access my site, I get site can not be reached. I feel like there’s router settings I need also, otherwise how does a request that google directs to my ip, then get directed from my router to my pc? Do I need to port forward 80 and 443?

See below. I’m not sure what you mean by ‘the same Docker network’, but Caddy and Komga are both running in the same Docker on the same Windows PC. I’m not sure why Caddy’s container is nested compared to Komga’s either based off the compose file.

francislavoie · November 7, 2021, 8:35pm

Troilus98:

So what confuses me about this statement is that I have Komga running a server in a Docker container, but I can access it via localhost:8080 in a web browser outside of the container. So it seems like conflicts to me about what can and can’t be accessed in/outside container terminals. For reference the Komga container was setup via command line with:
 docker create --name=komga --user 1000:1000 -p 8080:8080 --mount type=bind,source=C:\Komga\config,target=/config --mount type=bind,source=D:\-=_Comics_=-,target=/data   --restart unless-stopped gotson/komga

The reason you’re able to access komga is because you bound port 8080 to the host, with the option -p 8080:8080. This makes it so requests that reach your host machine on port 8080, will be routed to the container’s port 8080.

For Caddy, you similarly have ports 80 bound to 80, and 443 to 443. But you don’t have port 2019 bound.

But even if you did bind port 2019 to the host, it wouldn’t work just with that, because Caddy only listens to requests on localhost:2019, which means it will reject any requests not coming from inside the container. This can be reconfigured to be more permissive, but that adds risk because you want to be sure that nobody but yourself can access the admin API. By default there’s also no authentication for the admin API so someone could reconfigure your server to do whatever they like, and potentially do bad things.

If you were to run Caddy outside of Docker, then these things aren’t issues, because these are complications introduced by Docker’s network isolation (which is an advantage, but it just makes it harder to do certain things, and other things easier).

That’s because Caddy and Komga are not in the same docker network. See the docs Networking in Compose | Docker Docs. When you run the two containers separately, one with docker-compose and the other with docker create, then they won’t share the same network, unless you tell Docker to do so.

Docker has “virtual networks”, which is how it can isolate some containers from others, so you could run two different projects on the same machine, and those projects could use the same service names (for example, you could be running a database container for your two projects and they could have the same service name mysql, and not conflict).

The simplest solution is to move your Komga service to your docker-compose.yml file, because if you have them both in the same file, you can just run a single command to run both services at the same time, and they’ll be in the same Docker network automatically. Then doing reverse_proxy komga:8080 will just work.

I think Docker Desktop will show it nested like that because it detected that you used docker-compose to run Caddy, and your one docker-compose.yml file can contain multiple services. So it groups that up.

Troilus98 · November 7, 2021, 9:51pm

So I made the change you suggested and combined komga in the compose file so now they both show up in a single Docker group. I think I’m making progress because now I think I’m getting a different error when I try to connect over the internet to my site at komga.troilus98.com. For reference, new configuration looks like below:

Compose:

version: "3.7"

services:
  caddy:
    image: caddy:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - caddy_data:/data
      - caddy_config:/config
      - C:\Caddy\Caddyfile:/etc/caddy/Caddyfile
  komga:
    image: gotson/komga
    volumes:
      - type: bind
        source: C:\Komga\config
        target: /config
      - type: bind
        source: D:\-=_Comics_=-
        target: /data
      - type: bind
        source: /etc/timezone
        target: /etc/timezone
        read_only: true
    ports:
      - 8080:8080
    user: "1000:1000"
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

Caddyfile

komga.troilus98.com {
	reverse_proxy http://caddy-komga-1:8080	
}

Via browser over internet I still get " The webpage at https://komga.troilus98.com/ might be temporarily down or it may have moved permanently to a new web address. ERR_TUNNEL_CONNECTION_FAILED." Suggestions?

francislavoie · November 7, 2021, 10:17pm

That looks better!

You don’t need to specify the full container name btw, you can just use the service name as found in your docker-compose.yml, it will resolve to the same IP address, and not be dependent on the “project name” (i.e. the directory it’s in) and the instance number (i.e. 1, unlikely you’ll be launching more than once instance, but still). So you can do simply reverse_proxy komga:8080. Also http:// is implicit.

Try making the request with curl -v, it’ll provide more detail. Browsers aren’t the best tool to use when checking that a server is working, because they often have weird caching behaviour which can throw things off.

What do you see in Caddy’s logs? You can run docker-compose logs caddy to check them.

Do you have ports 80 and 443 forwarded to your machine on your router? (I assume this is in a home network?) Is your Windows Firewall allowing incoming connections on ports 80 and 443?

Troilus98 · November 7, 2021, 10:48pm

Almost there! So as I was adding all the logs and trying to shorten the caddy log for post, I restarted the caddy&komga container, and now I can access the site over the internet now. So I think the issue is nearly solved. The site appears to be running with a secure connection in the VPN’d browser I’m using to test over the internet, but the logs in docker/caddy are still filling up with the last line you see in those logs below. I don’t know if this is a serious issue, but maybe I can fix it just to make sure it’s all running smoothly.

curl -v komga.troilus98.com

PS C:\Caddy> curl -v komga.troilus98.com
* Rebuilt URL to: komga.troilus98.com/
*   Trying 67.4.148.230...
* TCP_NODELAY set
* Connected to komga.troilus98.com (67.4.148.230) port 80 (#0)
> GET / HTTP/1.1
> Host: komga.troilus98.com
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 200 Ok
< Server: micro_httpd
< Cache-Control: no-cache
< Date: Sun, 07 Nov 2021 22:56:34 GMT
< Content-Type: text/html
< Connection: close
<
<script type="text/javascript">
var exp = new Date();
exp.setTime(exp.getTime()-1000);
document.cookie = "Authorization= ;path=/;expires="+exp.toGMTString();
document.cookie = "CLINK_SESSION_ID= ;path=/;expires="+exp.toGMTString();
document.cookie = "record_page= ;expires="+exp.toGMTString();
document.cookie = "toptab= ;expires="+exp.toGMTString();
document.cookie = "loginaccount= ;path=/;expires="+exp.toGMTString();
window.location.href = "/clink_login.html"
</script>
* Closing connection 0

docker-compose logs caddy

{"level":"info","ts":1636324718.5490298,"msg":"shutdown complete","signal":"SIGTERM","exit_code":0}

{"level":"info","ts":1636324758.7628279,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}

{"level":"warn","ts":1636324758.7646005,"msg":"input is not formatted with 'caddy fmt'","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":12}

{"level":"info","ts":1636324758.7660463,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}

{"level":"info","ts":1636324758.7663152,"logger":"http","msg":"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}

{"level":"info","ts":1636324758.7663932,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}

{"level":"info","ts":1636324758.7664537,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0000f7570"}

{"level":"info","ts":1636324758.7670014,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["komga.troilus98.com"]}

{"level":"info","ts":1636324758.767781,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}

{"level":"info","ts":1636324758.767788,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}

{"level":"info","ts":1636324758.768024,"msg":"serving initial configuration"}

{"level":"info","ts":1636324758.7688317,"logger":"tls","msg":"finished cleaning storage units"}

{"level":"error","ts":1636324827.885389,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636324827.8854704,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636324827.9859943,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636324827.9860654,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636324841.7613108,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636324841.7613804,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636324841.8687067,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636324841.869194,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

francislavoie · November 7, 2021, 11:12pm

This looks strange to me. Firstly, you’re making an HTTP request here, not HTTPS (you should prefix the address with https:// to make sure it does), and the Server header doesn’t report Caddy. So I don’t think you’re actually reaching Caddy here.

Are you sure your port forwarding is sending the request to the right machine? From the contents in the response, I see clink_login which from a quick google makes me think this is a response from Century Link, your ISP or your router. Something’s strange here.

This means Caddy tried to start issuance earlier, but wasn’t able to solve it, and now it can’t find the challenge data in storage. So the storage got in a bad state somehow. Not sure why.

Troilus98 · November 7, 2021, 11:39pm

Ports 80, 443 are definitely fowarded to my pc. I am behind a century link router. No telling what shenanigans go on there.

Is there something I should to do fix this? I can easily delete and recreate the caddy container now if that would fix it?

PS C:\Caddy> curl -v https://komga.troilus98.com
* Rebuilt URL to: https://komga.troilus98.com/
*   Trying 67.4.148.230...
* TCP_NODELAY set
* Connected to komga.troilus98.com (67.4.148.230) port 443 (#0)
* schannel: SSL/TLS connection with komga.troilus98.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 190 bytes...
* schannel: sent initial handshake data: sent 190 bytes
* schannel: SSL/TLS connection with komga.troilus98.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with komga.troilus98.com port 443 (step 2/3)
* schannel: encrypted data got 1343
* schannel: encrypted data buffer: offset 1343 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with komga.troilus98.com port 443
* schannel: clear security context handle
curl: (77) schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.

francislavoie · November 8, 2021, 1:53am

Your router might still be hijacking those ports to show its own web UI though. You’ll need to dig into that.

Troilus98 · November 11, 2021, 12:08am

So I’m not sure what happened. The reverse proxy was working Saturday night, albeit with that error, but when I restarted it yesterday to mess with, it was no longer working. Any idea what happened? I didn’t change anything besides turn it off one day and on again later.

logs

{"level":"info","ts":1636588642.009567,"msg":"shutdown complete","signal":"SIGTERM","exit_code":0}

{"level":"info","ts":1636588966.5860264,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}

{"level":"warn","ts":1636588966.5877047,"msg":"input is not formatted with 'caddy fmt'","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":12}

{"level":"info","ts":1636588966.5894728,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}

{"level":"info","ts":1636588966.5899518,"logger":"http","msg":"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}

{"level":"info","ts":1636588966.5899935,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0002593b0"}

{"level":"info","ts":1636588966.5900528,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}

{"level":"info","ts":1636588966.5908177,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["komga.troilus98.com"]}

{"level":"info","ts":1636588966.590831,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}

{"level":"info","ts":1636588966.5924366,"logger":"tls","msg":"finished cleaning storage units"}

{"level":"info","ts":1636588966.5933383,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}

{"level":"info","ts":1636588966.5933914,"msg":"serving initial configuration"}

{"level":"error","ts":1636589007.6262681,"logger":"http.log.error","msg":"dial tcp: i/o timeout","request":{"remote_addr":"172.20.0.1:54068","proto":"HTTP/2.0","method":"GET","host":"komga.troilus98.com","uri":"/","headers":{"Sec-Ch-Ua-Platform":["\"Windows\""],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36 OPR/80.0.4170.63"],"Accept-Language":["en-US,en;q=0.9"],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-Dest":["document"],"Cookie":["SESSION=NTE5ZWI0YWMtMDdjNS00OGY3LTg4MGItOWQ1Zjg4NDZhZDJm"],"Sec-Ch-Ua":["\"Chromium\";v=\"94\", \" Not A;Brand\";v=\"99\", \"Opera\";v=\"80\""],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Accept-Encoding":["gzip, deflate, br"],"Cache-Control":["max-age=0"],"Upgrade-Insecure-Requests":["1"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","proto_mutual":true,"server_name":"komga.troilus98.com"}},"duration":10.00448137,"status":502,"err_id":"3b43ba02z","err_trace":"reverseproxy.statusError (reverseproxy.go:858)"}

{"level":"error","ts":1636589067.8867686,"logger":"http.log.error","msg":"dial tcp: i/o timeout","request":{"remote_addr":"172.20.0.1:54070","proto":"HTTP/2.0","method":"GET","host":"komga.troilus98.com","uri":"/","headers":{"Accept-Language":["en-US,en;q=0.9"],"Cache-Control":["max-age=0"],"Sec-Fetch-Site":["none"],"Sec-Fetch-User":["?1"],"Accept-Encoding":["gzip, deflate, br"],"Sec-Ch-Ua":["\"Chromium\";v=\"94\", \" Not A;Brand\";v=\"99\", \"Opera\";v=\"80\""],"User-Agent":["Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36 OPR/80.0.4170.63"],"Cookie":["SESSION=NTE5ZWI0YWMtMDdjNS00OGY3LTg4MGItOWQ1Zjg4NDZhZDJm"],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Ch-Ua-Platform":["\"Windows\""],"Upgrade-Insecure-Requests":["1"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-Dest":["document"]},"tls":{"resumed":true,"version":772,"cipher_suite":4865,"proto":"h2","proto_mutual":true,"server_name":"komga.troilus98.com"}},"duration":10.004958643,"status":502,"err_id":"pn0pssebv","err_trace":"reverseproxy.statusError (reverseproxy.go:858)"}

{"level":"error","ts":1636589230.5448005,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636589230.54487,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636589230.6465602,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636589230.6466393,"logger":"tls.issuance.acme","msg":"looking up info for HTTP challenge","host":"komga.troilus98.com","error":"no information found to solve challenge for identifier: komga.troilus98.com"}

{"level":"error","ts":1636589240.6470518,"logger":"http.log.error","msg":"dial tcp: i/o timeout","request":{"remote_addr":"172.20.0.1:54074","proto":"HTTP/1.1","method":"GET","host":"komga.troilus98.com","uri":"/.well-known/acme-challenge/K6P6DI1R_WpMUXQSfxo6pEuItfXLyhUZ35uNHx5sD2E","headers":{"Connection":["close"],"User-Agent":["acme.zerossl.com/v2/DV90"],"Cache-Control":["no-cache"],"Referer":["http://komga.troilus98.com/.well-known/acme-challenge/K6P6DI1R_WpMUXQSfxo6pEuItfXLyhUZ35uNHx5sD2E"],"Accept-Encoding":["gzip"]},"tls":{"resumed":false,"version":772,"cipher_suite":4867,"proto":"","proto_mutual":true,"server_name":"komga.troilus98.com"}},"duration":10.000534613,"status":502,"err_id":"xwz9bsy9r","err_trace":"reverseproxy.statusError (reverseproxy.go:858)"}

PS C:\Users\ikerz> curl -v komga.troilus98.com
* Rebuilt URL to: komga.troilus98.com/
*   Trying 67.4.148.230...
* TCP_NODELAY set
* Connected to komga.troilus98.com (67.4.148.230) port 80 (#0)
> GET / HTTP/1.1
> Host: komga.troilus98.com
> User-Agent: curl/7.55.1
> Accept: */*
>
< HTTP/1.1 200 Ok
< Server: micro_httpd
< Cache-Control: no-cache
< Date: Thu, 11 Nov 2021 00:05:02 GMT
< Content-Type: text/html
< Connection: close
<
<script type="text/javascript">
var exp = new Date();
exp.setTime(exp.getTime()-1000);
document.cookie = "Authorization= ;path=/;expires="+exp.toGMTString();
document.cookie = "CLINK_SESSION_ID= ;path=/;expires="+exp.toGMTString();
document.cookie = "record_page= ;expires="+exp.toGMTString();
document.cookie = "toptab= ;expires="+exp.toGMTString();
document.cookie = "loginaccount= ;path=/;expires="+exp.toGMTString();
window.location.href = "/clink_login.html"
</script>
* Closing connection 0

francislavoie · November 11, 2021, 12:25am

Again, you’re not hitting Caddy at all with that curl request, you’re hitting your CenturyLink router I think.

You’re running in Docker, right? Is your komga container running? This error means Caddy couldn’t reach it.

Troilus98 · November 11, 2021, 12:58am

Yeah komga is running. It’s accessible locally. I’ve tried starting it before and after caddy stars, restarting caddy, and nothing. Those sound like 2 different problems. Why would caddy not be able to reach Komga if nothing about settings have changed? I’m not sure what to change about the router settings; remote gui is disabled and port are properly forwarded. Aside from getting a new router.

Troilus98 · November 11, 2021, 1:33am

Hmm. I guess Docker changed the name or something, but the names for the containers in Docker are “caddy_komga_1” and “caddy_caddy_1” today. In my Caddy file I had reverse proxy to “caddy-komga-1”. So I guess the docker container names changed? I changed the hypens to underscores and it connects again.

francislavoie · November 11, 2021, 2:01am

You should use reverse_proxy komga:8080, like I wrote earlier:

Troilus98 · November 11, 2021, 3:27pm

I’m sorry Caddy Master LaVoie, I did not listen.

Troilus98 · November 12, 2021, 3:02am

Is there a reason why my server would be accessible from any browser on a PC, but not from a mobile device? Aka ipad/iphone? I only get the error in the browser “The Site can’t be reached. The network connection was lost.” And I see no messages in the caddy logs about an attempted connection.

francislavoie · November 12, 2021, 3:25am

It depends on your networking setup. We know your router is likely unreliable because the CenturyLink stuff seems to be intercepting requests. I really can’t say much more, because I don’t have a good picture of your networking situation.

Troilus98 · November 12, 2021, 3:38am

I found out, I can’t load my server internally on my network using the reverse proxy, but when I turned off wifi and used cellular, it loaded. I suppose I might need a different address on local network, but this isn’t a huge problem for me. I was just concerned any outside user wouldn’t be able to use a mobile device too.

francislavoie · November 12, 2021, 3:57am

That’s typically because your router doesn’t know how to do NAT hairpinning, i.e. doesn’t know how to deal with packets destined for your WAN IP address and route them back into your network, and instead just drops the packets.

The solution for this is typically to run a DNS server in your home network that makes sure that your domain resolves to a LAN IP address for any devices inside your network, but devices outside your network will use public DNS which resolve to your WAN IP address. This is called Split-horizon DNS - Wikipedia.

If you already have a Pihole for example, you could easily configure it to override DNS in your local network, or your could run CoreDNS, a DNS server written in Go (was originally based on Caddy v1! Similar config structure).

Caddy Setup Issue - Address already in use

1. Caddy version (caddy version):

2. How I run Caddy:

a. System environment:

b. Command:

c. Service/unit/compose file:

d. My complete Caddyfile or JSON config:

3. The problem I’m having:

4. Error messages and/or full log output:

5. What I already tried:

6. Links to relevant resources:

1. Caddy version (`caddy version`):