Wordpress reverse proxy not working

[FrankWard (Frank)]

1. The problem I’m having:

I have Caddy working on several Cloudflare domains using reverse-proxy to my internal Docker apps. However, A basic Wordpress install refuses to load. I can access the Wordpress site from it’s IP fine. Everything works, so I’m guessing there’s something missing from the Caddy config that’s particular to getting Wordpress to behave.

2. Error messages and/or full log output:

Unable to connect
An error occurred during a connection to wp.cfdomain.net:8888.

3. Caddy version:

v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

4. How I installed and ran Caddy:

Docker Compose

a. System environment:

Docker version 24.0.6, build ed223bc

d. My complete Caddy config:

#----------------------------------------------- 
# CADDYFILE
#----------------------------------------------- 

# LOCAL Domain
localhost {
  respond "Hello, world!"
}

#----------------------------------------------- 
# BYPASS
#----------------------------------------------- 

# AUTHELIA
auth.cfdomain.net {
  #authelia
  reverse_proxy authelia:9091
}

# NGINX
cfdomain.net {
  reverse_proxy 192.168.1.33:8081
}

# WORDPRESS
wp.cfdomain.net {
  reverse_proxy 192.168.1.33:8888
}

#----------------------------------------------- 
# 1-FACTOR
#----------------------------------------------- 

# AIRSONIC
music.cfdomain.net {
        forward_auth authelia:9091 {
                uri /api/authz/forward-auth                
                copy_headers Remote-User Remote-Groups Remote-Email Remote-Name
        }

        reverse_proxy 192.168.1.35:4040
}

[Whitestrake (Matthew Fay)]

@FrankWard

a. System environment:

Docker version 24.0.6, build ed223bc

d. My complete Caddy config:

Are you able to post the missing parts b. and c. here? Specifically, the command used and the compose file. These help inform helpers how your Docker environment is wired up and how things connect.

• We want to help you, but if you ignore or skip questions in this template, we will just ask you to fill it out anyway.

Can you also try running curl -vL on the domain you’ve configured Caddy for? (I don’t believe cfdomain.net is registered, so I’ll assume you’ve redacted your actual domain.)

## 1. The problem I'm having:
<!-- What are you trying to do? What isn't working? Please describe the issue thoroughly enough so that anyone can reproduce the exact behavior you're seeing. Be as specific as possible. Use `curl -vL` to show example requests. DO NOT USE WEB BROWSERS HERE. Browsers have subtle caching behaviours which can make testing difficult. -->

[FrankWard (Frank)]

I feel bad that I didn’t try curl. I was able to solve the issue I was having by adding http:// in front of the site address. I cannot always share the configs I’m working on as they belong to client resources that need to stay out of public view, but I do my best to make the problem as clear as I can using a substitute that shouldn’t have an effect on the solve. Is there a proper procedure for sharing sensitive info here?

# WORDPRESS
wp.cfdomain.net {
  reverse_proxy http://192.168.1.33:8888
}

[Whitestrake (Matthew Fay)]

These forums are powered by volunteers whose goal is to provide help for as many people as possible on a best-effort basis. We don’t typically provide private support here, although any of our users might reach out with an offer of help and we don’t prevent that either.

That said, if you need private support for commercial purposes, I’d recommend considering sponsoring Caddy directly to get access to business tier support: Caddy help & support

[FrankWard (Frank)]

Thanks for the info @Whitestrake.

[francislavoie]

@FrankWard

I was able to solve the issue I was having by adding http:// in front of the site address.

Two things:

• That’s not the site address, that’s the proxy upstream address. The site address is the wp.cfdomain.net part (the “site” is the “site address” + { ... } stuff that follows it). See Caddyfile Concepts — Caddy Documentation
• Adding http:// to the upstream address has no effect at all. See reverse_proxy (Caddyfile directive) — Caddy Documentation which explains.

Your problem was probably elsewhere, and you happened to fix it between the two times you tested it.

[FrankWard (Frank)]

Thanks. My site kept redirecting to HTTPS:PORT for some reason. The culprit was likely caching? even though I cleared and tried multiple browsers. In the back of my mind I wondered the same thing, but a suggestion said this would force the site to use HTTP which I now see " Using http:// as the scheme is identical to having omitted the scheme, since HTTP is already the default."

I put Caddy down for a few months and just got back to it. My terminology will lock in eventually. I spent a day getting Nginx PM and Authentik up and running, but they had their own set of issues.