Resources loading with blank content when behind reverse proxy

[Aaron_Miller]

1. Caddy version (caddy version):

See #2

2. How I run Caddy:

docker-compose.yml

version: "3.1"

services:
  caddy:
    image: caddy/caddy:2.2.1-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./etc/caddy/Caddyfile:/etc/caddy/Caddyfile
      - ./.caddy/data:/data
      - ./.caddy/config:/config

  www:
    image: demos/hello:plain-text
    hostname: www.watheia.dev
    container_name: hello-app
    depends_on:
      - caddy

etc/caddy/Cadyfile

{
    # Global options block. Entirely optional, https is on by default
    # Optional email key for lets encrypt
    email admin@watheia.dev
    # Optional staging lets encrypt for testing. Comment out for production.
    # acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

www.watheia.dev {
    reverse_proxy / www:80
}

netdata.watheia.dev {
  reverse_proxy / http://128.199.11.45:19999
}

a. System environment:

Linux 5.4.0-51-generic amd64

b. Command:

docker-compose up -d

c. Service/unit/compose file:

paste full file contents here

d. My complete Caddyfile or JSON config:

paste config here, replacing this text
DO NOT REDACT anything except credentials

3. The problem I’m having:

I am having trouble figuring out random strange behavior when serving standard web containers behind reverse proxy. For example:

https://www.watheia.dev/

Simple hello world is fine.

But then…

https://my-app.watheia.dev/

Default create-react-app loads with a blank manifest.json, even though the file exists in the container.

Also…

http://128.199.11.45:19999/ (this is fine)
https://netdata.watheia.dev/ (this loads a bunch of blank files)

There are no actual network errors being reported, so I’m not sure how to go about debugging the issue.

4. Error messages and/or full log output:

5. What I already tried:

6. Links to relevant resources:

[francislavoie]

In Caddy v2, path matching is exact-match. Please read this section of the docs:

Request matchers (Caddyfile) - Caddy Documentation

For your usecase, just remove the / from your reverse_proxy directives and it should work just fine.

A matcher of / only matches exactly /, so nothing else will be handled. An unhandled request will return an empty 200 response (because technically, Caddy did exactly what it was configured to do, there’s no error).

Also, please use image: caddy:2.2.1-alpine instead, caddy/caddy is not the official image, it’s basically the “placeholder” between the official image and our release process.

[Aaron_Miller]

Ugg, it’s so obvious when I state the problem as, “everything past / fails to load.”

Thanks for the help, and tip on the image name!