Caddy not redirecting requests nor accepting requests to its admin API

1. The problem I’m having:

I’m trying to setup caddy, apache and mysql with docker-compose, I have three issues:

  1. On sending a request to caddy to forward it to apache I get a “200” empty response from caddy server instead.
    For test’s sake I mapped apache container to host port and sent a request directly to apache with curl and it works just ok.

  2. I want to expose caddy api and get 403 error response from the host machine.

  3. I’m not able to reload with this actual Caddyconf even from inside the caddy-running container

This is my docker-compose.yml:

version: '3.7'

services:
  mysql:
    image: mysql:latest
    environment:
      - MYSQL_ROOT_PASSWORD=admin123
    
    ports:
      - 3306:3306
    volumes:
      - ./initdb.sql:/docker-entrypoint-initdb.d/initdb.sql
    networks:
      - internal
      
  apache:
    image: d3vr10/apache:php8.1
    tty: true
    # ports:
    #   - 80:80
    environment:
      - TZ=UTC
    volumes:
      - /home/d3vr10/web_project/wordpress:/var/www/html
      - ./apache2:/etc/apache2
    networks:
      - internal
      - webserver
    

  caddy:
    image: caddy:latest
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
      - "2019:2019"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./site:/srv
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - webserver


volumes:
  caddy_data:
  caddy_config:

networks:
  webserver:
    external: false
  internal:
    external: false

And here is my Caddyfile:

{
	admin caddy:2019 {
		origins *:2019
	}
	http_port 80
	debug
}

caddy:80 {
	reverse_proxy http://apache:80 {
		header_up Host "apache"
	}
}

2. Error messages and/or full log output:

Log for the 1st problem:

curl -vL localhost:80
*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/8.1.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Caddy
< Date: Sun, 28 May 2023 20:56:45 GMT
< Content-Length: 0
< 
* Connection #0 to host localhost left intact

Log for the 2nd problem:

curl -vL localhost:2019
*   Trying 127.0.0.1:2019...
* Connected to localhost (127.0.0.1) port 2019 (#0)
> GET / HTTP/1.1
> Host: localhost:2019
> User-Agent: curl/8.1.1
> Accept: */*
> 
< HTTP/1.1 403 Forbidden
< Content-Type: application/json
< Date: Sun, 28 May 2023 21:10:50 GMT
< Content-Length: 45
< 
{"error":"host not allowed: localhost:2019"}
* Connection #0 to host localhost left intact

Logs for the 3rd problem: ( When I execute caddy reload --config /etc/caddy/Caddyconf

2023/05/28 21:49:52.417 INFO    using provided configuration    {"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""}
Error: sending configuration to instance: caddy responded with error: HTTP 403: {"error":"host not allowed: caddy:2019"}

3. Caddy version:

v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

4. What I’ve tried so far:

Checked for similar solutions provided here, but none of them worked for me for docker, changed the origins to 0.0.0.0:2019, *:2019 and the very container ip address:2019. Also played around with the admin ip address and did the same thing except I set the admin ip to localhost too. I’ve ran through the docs but cannot make sense of something that could tackle these 3 issues so far.

Any help is appreciated.

You configured Caddy to look for a hostname caddy but you made requests to localhost, which is not a match.

If you want to accept requests from any hostname on port 80, use :80 instead of caddy:80.

Same here, caddy is not localhost. You can use :2019 instead.

Be careful with this though if you’re publishing this port to your host machine, because any client which can make requests to port 2019 on that machine (possibly anything on your network, or if you don’t have a firewall/port forwarding preventing the connection, public clients could reach it), allowing them to change your config and do evil things.

2 Likes

Yes! it worked like a charm. Though it’s weird to me that 0.0.0.0:port does not yield the same result as with the “:port” construct.

And, thanks for the advice.

That’s because 0.0.0.0 would be a host matcher as well, and would never match because you’d never use that as the hostname in the request.

2 Likes

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