Help API calls not being proxied to another Docker container

[icetea5 (John Frecht)]

1. Caddy version (caddy version):

2.3.0

2. How I run Caddy:

Running inside Docker

a. System environment:

Docker

b. Command:

Currently I have multiple docker-compose files so I run like this

docker-compose -f docker-compose-fe.yml up -d
docker-compose -f docker-compose-be.yml up -d

c. Service/unit/compose file:

Dockerfile

FROM caddy:2.3.0-alpine
COPY Caddyfile /etc/caddy/Caddyfile
COPY /usr/src/app/dist/project-fe /srv

docker-compose-fe.yml

services:
  project-fe:
    image: project-fe:latest
    container_name: project-fe
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./caddydata:/data
      - ./caddyconfig:/config

networks:
  default:
    external:
      name: project-network

docker-compose-be.yml

services:
  project-be:
    image: project-be:latest
    container_name: project-be
    ports:
      - 8080

networks:
  default:
    external:
      name: project-network

d. My complete Caddyfile or JSON config:

{
	debug
}
dev.domain.xyz {
  root * /srv
  try_files {path} /index.html
  reverse_proxy /api/* http://project-be:8080
  file_server
  encode zstd gzip

basicauth * {
  	icetea5  bWFuYWdlcjo...=
  }
}

3. The problem I’m having:

Currently I’m having a backend and frontend running in same Docker machine in different containers.
I have REST API on backend container with the path of /api/test and I’m trying it to access through frontend and the response that I’m getting is the contents of index.html file And feels like the requests doesn’t get proxied to the backend container

4. Error messages and/or full log output:

{
  "level": "info",
  "ts": 1618171112.2697785,
  "logger": "http.log.access",
  "msg": "handled request",
  "request": {
    "remote_addr": "xx.xx.xxx.x:xxxxx",
    "proto": "HTTP/2.0",
    "method": "GET",
    "host": "dev.domain.xyz",
    "uri": "/api/test",
    "headers": {
      "Accept-Language": [
        "en-US,en;q=0.9,lt;q=0.8"
      ],
      "Sec-Ch-Ua": [
        "\"Google Chrome\";v=\"89\", \"Chromium\";v=\"89\", \";Not A Brand\";v=\"99\""
      ],
      "Accept": [
        "application/json, text/plain, */*"
      ],
      "Sec-Ch-Ua-Mobile": [
        "?0"
      ],
      "Sec-Fetch-Mode": [
        "cors"
      ],
      "Sec-Fetch-Dest": [
        "empty"
      ],
      "Authorization": [
        "Basic bWFuYWdlcjo...="
      ],
      "User-Agent": [
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36"
      ],
      "Sec-Fetch-Site": [
        "same-origin"
      ],
      "Referer": [
        "https://dev.domain.xyz/"
      ],
      "Accept-Encoding": [
        "gzip, deflate, br"
      ]
    },
    "tls": {
      "resumed": true,
      "version": 772,
      "cipher_suite": 4865,
      "proto": "h2",
      "proto_mutual": true,
      "server_name": "dev.domain.xyz"
    }
  },
  "common_log": "xx.xx.xxx.x - icetea5 [11/Apr/2021:19:58:32 +0000] \"GET /api/test HTTP/2.0\" 200 1260",
  "duration": 0.000859889,
  "size": 1260,
  "status": 200,
  "resp_headers": {
    "Content-Type": [
      "text/html; charset=utf-8"
    ],
    "Last-Modified": [
      "Sun, 11 Apr 2021 19:38:35 GMT"
    ],
    "Content-Encoding": [
      "gzip"
    ],
    "Vary": [
      "Accept-Encoding"
    ],
    "Server": [
      "Caddy"
    ],
    "Etag": [
      "\"qrezwb5pp\""
    ]
  }
}

5. What I already tried:

Pretty much tried reading googling as much as possible but didn’t seemd to find an answer. All I did was double check if containers are connected correctly, I’ve tried to ssh into Caddy container and from there execute:

wget http://project-be:8080/api/test

to backend container and got response that I was expecting it
and I get the desired response from REST API. So I assume that the Docker configuration should be alright, but perhaps there is an issue I’m not aware in the Caddyfile configuration

[francislavoie]

The problem you’re having is that try_files runs before reverse_proxy does, because Caddyfile directives are ordered according to this list:

Caddyfile Directives - Caddy Documentation

So to get around this, I recommend using handle blocks:

dev.domain.xyz {
	basicauth {
		icetea5  bWFuYWdlcjo...=
	}

	encode zstd gzip

	handle /api* {
		reverse_proxy project-be:8080
	}

	handle {
		root * /srv
		try_files {path} /index.html
		file_server
	}
}