All of my website's file links redirect to https: // ip / ... and are unavailable

1. Caddy version

I am using the docker image 2.4.3

2. How I run Caddy:

a. System environment:

Google Compute Engine, Ubuntu 20.04LTS, Docker-compose

b. Command

sudo docker-compose up -d

c. Service/unit/compose file:

docker-compose.yml

version: "3.8"

services:
  postgres:
    image: "postgis/postgis:12-3.1"
    volumes:
      - "./postgresql-data:/var/lib/postgresql/data"
    env_file:
      - ".env"

  web:
    container_name: cl-docker-back-web
    depends_on:
      - "postgres"
      - "rabbitmq"
      - 'memcached'
    image: citizenlabdotco/back-essential:${CL_VERSION}
    volumes:
      - "./uploads:/cl2_back/public/uploads"
    env_file:
      - ".env"
    environment:
      RAILS_ENV: production

  que:
    container_name: cl-docker-que
    depends_on:
      - "postgres"
      - "rabbitmq"
    image: citizenlabdotco/back-essential:${CL_VERSION}
    command: bundle exec que
    volumes:
      - "./uploads:/cl2_back/public/uploads"
    env_file:
      - ".env"
    environment:
      RAILS_ENV: production

  rabbitmq:
    container_name: cl-docker-back-rabbit
    image: "rabbitmq:3.7"

  front:
    container_name: cl-docker-front
    image: citizenlabdotco/front-essential:${CL_VERSION}
    environment:
      NODE_ENV: production
    env_file:
      - ".env"
    command: npm run start:production

  memcached:
    image: memcached:alpine
    command: memcached -m 64

  caddy:
    image: caddy:2
    restart: unless-stopped
    depends_on:
      - "web"
      - "front"
    ports:
      - "80:80"
      - "443:443"
    env_file:
      - ".env"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - "./uploads:/uploads:ro"
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:
networks:
  default:
    name: cl-docker

d. My complete Caddyfile or JSON config:

{$CL_SETTINGS_HOST} {

handle /uploads/* {
	root /uploads/* /uploads/
	uri strip_prefix /uploads
	file_server
}

@back_requests {
	path_regexp ^/(api|auth|web_api|admin_api|hooks)/(.*)$
}

reverse_proxy @back_requests web:4000 {
	header_up Host {http.reverse_proxy.upstream.hostport}
}

reverse_proxy front:3000
}

3. The problem I’m having:

All of my website’s file links redirect to https://ipaddress/… and are unavailable. While the website is available in https.
Here is my website : Plateforme d’engagement citoyen
It works fine in https but all images on the website are redirected to https with ip address.
For example image

4. Error messages and/or full log output:

caddy_1      | {"level":"info","ts":1626623553.2449303,"msg":"using provided configuration","
config_file":"/etc/caddy/Caddyfile","config_adapter":"caddyfile"}
caddy_1      | {"level":"warn","ts":1626623553.2521787,"msg":"input is not formatted with 'ca
ddy fmt'","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
caddy_1      | {"level":"info","ts":1626623553.2534876,"logger":"admin","msg":"admin endpoint
 started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["127.0.0.1:2019","
localhost:2019","[::1]:2019"]}
caddy_1      | {"level":"info","ts":1626623553.253858,"logger":"http","msg":"server is listen
ing only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","ser
ver_name":"srv0","https_port":443}
caddy_1      | {"level":"info","ts":1626623553.2539544,"logger":"http","msg":"enabling automa
tic HTTP->HTTPS redirects","server_name":"srv0"}
caddy_1      | {"level":"info","ts":1626623553.254557,"logger":"tls.cache.maintenance","msg":
"started background certificate maintenance","cache":"0xc0002f2930"}
caddy_1      | {"level":"info","ts":1626623553.2551908,"logger":"tls","msg":"cleaning storage
 unit","description":"FileStorage:/data/caddy"}
caddy_1      | {"level":"info","ts":1626623553.2555933,"logger":"http","msg":"enabling automa
tic TLS certificate management","domains":["efricaeven.xyz"]}
caddy_1      | {"level":"info","ts":1626623553.2575479,"msg":"autosaved config (load with --r
esume flag)","file":"/config/caddy/autosave.json"}
caddy_1      | {"level":"info","ts":1626623553.2575707,"msg":"serving initial configuration"}
caddy_1      | {"level":"info","ts":1626623553.269935,"logger":"tls.obtain","msg":"acquiring 
lock","identifier":"efricaeven.xyz"}
caddy_1      | {"level":"info","ts":1626623553.2735283,"logger":"tls.obtain","msg":"lock acqu
ired","identifier":"efricaeven.xyz"}
caddy_1      | {"level":"info","ts":1626623553.2789135,"logger":"tls","msg":"finished cleanin
g storage units"}
caddy_1      | {"level":"info","ts":1626623553.2916324,"logger":"tls.issuance.acme","msg":"wa
iting on internal rate limiter","identifiers":["efricaeven.xyz"],"ca":"https://acme-v02.api.l
etsencrypt.org/directory","account":""}
caddy_1      | {"level":"info","ts":1626623553.291687,"logger":"tls.issuance.acme","msg":"don
e waiting on internal rate limiter","identifiers":["efricaeven.xyz"],"ca":"https://acme-v02.a
pi.letsencrypt.org/directory","account":""}
caddy_1      | {"level":"info","ts":1626623554.4986742,"logger":"tls.issuance.acme.acme_clien
t","msg":"trying to solve challenge","identifier":"efricaeven.xyz","challenge_type":"tls-alpn
-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
caddy_1      | {"level":"info","ts":1626623554.712157,"logger":"tls","msg":"served key authen
tication certificate","server_name":"efricaeven.xyz","challenge":"tls-alpn-01","remote":"3.12
0.130.29:53784","distributed":false}
caddy_1      | {"level":"info","ts":1626623555.2380934,"logger":"tls","msg":"served key authe
ntication certificate","server_name":"efricaeven.xyz","challenge":"tls-alpn-01","remote":"34.
221.186.243:38600","distributed":false}
caddy_1      | {"level":"info","ts":1626623555.6376555,"logger":"tls","msg":"served key authe
ntication certificate","server_name":"efricaeven.xyz","challenge":"tls-alpn-01","remote":"66.
133.109.36:63076","distributed":false}
caddy_1      | {"level":"info","ts":1626623562.0196528,"logger":"tls","msg":"served key authe
ntication certificate","server_name":"efricaeven.xyz","challenge":"tls-alpn-01","remote":"3.1
42.122.14:64032","distributed":false}
caddy_1      | {"level":"info","ts":1626623562.5180855,"logger":"tls.issuance.acme.acme_clien
t","msg":"validations succeeded; finalizing order","order":"https://acme-v02.api.letsencrypt.
org/acme/order/130923747/11168945457"}
caddy_1      | {"level":"info","ts":1626623563.3760011,"logger":"tls.issuance.acme.acme_clien
t","msg":"successfully downloaded available certificate chains","count":2,"first_url":"https:
//acme-v02.api.letsencrypt.org/acme/cert/03fff14661e0c87abf770c133440c3af5bd2"}
caddy_1      | {"level":"info","ts":1626623563.376623,"logger":"tls.obtain","msg":"certificat
e obtained successfully","identifier":"efricaeven.xyz"}
caddy_1      | {"level":"info","ts":1626623563.3766537,"logger":"tls.obtain","msg":"releasing
 lock","identifier":"efricaeven.xyz"}
caddy_1      | {"level":"error","ts":1626623645.9363115,"logger":"http.log.error","msg":"dial
 tcp 172.19.0.2:3000: connect: connection refused","request":{"remote_addr":"192.0.102.40:384
80","proto":"HTTP/1.1","method":"HEAD","host":"efricaeven.xyz","uri":"/","headers":{"Connecti
on":["close"],"User-Agent":["jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)"]},"tl
s":{"resumed":false,"version":771,"cipher_suite":49196,"proto":"","proto_mutual":true,"server
_name":"efricaeven.xyz"}},"duration":0.000956254,"status":502,"err_id":"hdn9cyraf","err_trace
":"reverseproxy.statusError (reverseproxy.go:857)"}
caddy_1      | {"level":"error","ts":1626623656.1458194,"logger":"http.log.error","msg":"dial
 tcp 172.19.0.2:3000: connect: connection refused","request":{"remote_addr":"89.19.180.245:50
407","proto":"HTTP/1.1","method":"GET","host":"efricaeven.xyz","uri":"/","headers":{"User-Age
nt":["Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Firefox/52.0"],"Accept-Encoding":[
"gzip, deflate"],"Accept":["*/*"],"Connection":["keep-alive"]},"tls":{"resumed":false,"versio
n":772,"cipher_suite":4865,"proto":"","proto_mutual":true,"server_name":"efricaeven.xyz"}},"d
uration":0.001139357,"status":502,"err_id":"585jverr5","err_trace":"reverseproxy.statusError 
(reverseproxy.go:857)"}
caddy_1      | {"level":"error","ts":1626623656.9770398,"logger":"http.log.error","msg":"dial
 tcp 172.19.0.2:3000: connect: connection refused","request":{"remote_addr":"54.147.189.26:46
166","proto":"HTTP/2.0","method":"GET","host":"efricaeven.xyz","uri":"/sellers.json","headers
":{"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, 
like Gecko) Chrome/66.0.3359.181 Safari/537.36"],"Cache-Control":["no-cache"],"Accept-Languag
e":["en-US,en;q=0.9"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/
webp,image/apng,*/*;q=0.8"],"Accept-Encoding":["gzip"]},"tls":{"resumed":false,"version":772,
"cipher_suite":4865,"proto":"h2","proto_mutual":true,"server_name":"efricaeven.xyz"}},"durati
on":0.00110827,"status":502,"err_id":"a5t6pm9x4","err_trace":"reverseproxy.statusError (rever
seproxy.go:857)"}

5. What I already tried:

Need urgent help, please

I’m assuming the redirect is being issued by your upstream app’s server.

This line is probably your issue. This is making Caddy set the Host header to web which doesn’t make sense. Remove this line, so that your upstream sees the Host header as the same as the original request so it doesn’t redirect.

FWIW I would write your config like this:

{$CL_SETTINGS_HOST} {
	handle_path /uploads/* {
		root * /uploads/
		file_server
	}

	@backend path_regexp back ^/(api|auth|web_api|admin_api|hooks)/(.*)$
	handle @backend {
		reverse_proxy web:4000
	}

	handle {
		reverse_proxy front:3000
	}
}
1 Like

I have executed your code and the problem is still not resolved

Well, without more information, there’s not much I can do to help.

The issue must be with your backend, not with Caddy.

After deleting my database, I did a new migration and it works now. Thanks

1 Like

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