Bug & Request: FrankenPHP/Caddy Host Routing causes 502 Bad Gateway when behind reverse proxy (NPM/Cloudflare)

[ljc2221788-commits]

Is there an existing issue for this?

• I have searched the existing issues

Environment

- OS:Ubuntu 22.04.5 LTS
- PHP:system default
- LDAP Server:openldap

PLA Code

Docker hub

PLA Version

2.3.11

Current Behavior

When deploying the phpldapadmin container behind a reverse proxy (e.g., Nginx Proxy Manager or Cloudflare) with SSL termination, requests forwarded to the container result in a 502 Bad Gateway error on the reverse proxy.

This is because the internal FrankenPHP/Caddy web server performs strict host header checks/routing. When the external domain name passed in the Host header does not match the internal SERVER_NAME / Caddy route rules, Caddy rejects or ignores the connection, causing NPM to report a 502 error. However, accessing the container locally via curl http://127.0.0.1:8080 returns HTTP 200 OK without issues.

Expected Behavior

1. The container should allow requests with arbitrary or external Host headers by default (catch-all host routing like :80 or :8080), allowing seamless integration with external reverse proxies (NPM, Traefik, Caddy, Cloudflare).
2. Alternatively, provide an environment variable (e.g., SERVER_NAME=* or a flag to disable strict host matching) so users can easily bypass strict host header checks when running behind a proxy.

Steps To Reproduce

1. In an environment with an external reverse proxy (e.g., Nginx Proxy Manager / Caddy) configured for HTTPS/SSL termination for ldap.example.com.
2. Deploy the phpldapadmin container mapping port 8080 to the host network (e.g., app-net).
3. Point the reverse proxy's upstream host/IP to phpldapadmin:8080.
4. Access https://ldap.example.com from an external browser/client.
5. See error: The reverse proxy returns 502 Bad Gateway because FrankenPHP/Caddy inside the container rejects the unrecognized external Host header.

Relevant log output

Anything else?

UI / UX Enhancement Request:
By the way, as a side suggestion for future releases, it would be awesome if the phpLDAPadmin Web UI could receive a modern face-lift/refresh to make the overall interface cleaner, more intuitive, and responsive on modern browsers.

Thanks again to the maintainers for your time and efforts!

[leenooks]

When deploying the phpldapadmin container behind a reverse proxy (e.g., Nginx Proxy Manager or Cloudflare) with SSL termination, requests forwarded to the container result in a 502 Bad Gateway error on the reverse proxy.

I dont see this issue. All the demo servers are all behind caddy are working just fine.

[ljc2221788-commits]

Hi @leenooks,

Thanks for the quick reply! I investigated deeper and found the exact technical reason why it fails under standard reverse proxies like Nginx Proxy Manager (NPM) or Cloudflare, whereas your Caddy-to-Caddy demo works fine.

1. The Evidence (Plain HTTP Refusal)

When NPM (or any standard reverse proxy) attempts to upstream traffic via plain HTTP (http://phpldapadmin:8080), the container's internal Caddy/FrankenPHP instantly drops the TCP connection.

Running a local check on the host yields:

$ curl -I [http://127.0.0.1:8082](http://127.0.0.1:8082)
curl: (56) Recv failure: Connection reset by peer

Because Caddy inside the container resets plain HTTP connections on that port, NPM receives no HTTP response at all and immediately returns 502 Bad Gateway.
2. The Double-SSL & Header Conflict (500 Error)
If we force NPM to talk to the container via https:// scheme to bypass the reset:
 * NPM handles public SSL certificate (e.g. Let's Encrypt).
 * NPM establishes an internal HTTPS connection to Caddy's self-signed cert.
 * Upon accessing /login, the application throws 500 | SERVER ERROR due to X-Forwarded-Proto header mismatches and dual SSL termination handling.
3. Core Request
Could you please clarify or provide an option/environment variable (e.g., SERVE_HTTP=true or disabling strict HTTPS enforcement inside Caddy) so external proxies like NPM can simply forward plain HTTP traffic to port 8080 without encountering a connection reset?
Thank you!

<img width="1706" height="1280" alt="Image" src="https://github.com/user-attachments/assets/f2cf0e0e-f5b6-40fd-94f1-c0259b723166" />
<img width="1706" height="1280" alt="Image" src="https://github.com/user-attachments/assets/5ab9d695-731c-468c-bde3-b87ae054161d" />
<img width="1706" height="1280" alt="Image" src="https://github.com/user-attachments/assets/5a186dee-ae62-44a5-a40f-c931eb113728" />
<img width="1706" height="1280" alt="Image" src="https://github.com/user-attachments/assets/a7574fee-23b8-4e9b-a877-2c79e4ec41d0" />

[leenooks]

Again, its working just fine for me:

From inside the container:

/app $ curl -I http://127.0.0.1:8080
HTTP/1.1 200 OK
Cache-Control: no-cache, private
Content-Type: text/html; charset=utf-8
Date: Wed, 19 Aug 2026 23:40:43 GMT
Server: FrankenPHP Caddy
Set-Cookie: XSRF-TOKEN=...; expires=Thu, 20 Aug 2026 01:40:43 GMT; Max-Age=7200; path=/; samesite=lax
Set-Cookie: laravel_session=... expires=Thu, 20 Aug 2026 01:40:43 GMT; Max-Age=7200; path=/; httponly; samesite=lax

Outside the container:

/ # curl -I http://pla-web-ldapd-1:8080
HTTP/1.1 200 OK
Cache-Control: no-cache, private
Content-Type: text/html; charset=utf-8
Date: Wed, 19 Aug 2026 23:44:53 GMT
Server: FrankenPHP Caddy
Set-Cookie: XSRF-TOKEN=...; expires=Thu, 20 Aug 2026 01:44:53 GMT; Max-Age=7200; path=/; samesite=lax
Set-Cookie: laravel_session=...; expires=Thu, 20 Aug 2026 01:44:53 GMT; Max-Age=7200; path=/; httponly; samesite=lax