Clashes with Caddy Admin API when Server block is localhost as well

silverbackdan · June 4, 2025, 2:18pm

When I am trying to access the Caddy API it seems to serve my Franken PHP application from the php_server line which is within a server block for localhost.

I changed the global config in realtime and adjusted the port, then set it back again to 2019, then the API was responding… bug or implementation issue?

I could adjust the server block that is configured on localhost too, add a matcher to prevent the reverse proxy serving, but I’m not sure this feels totally right. Otherwise I could specify localhost ports explicitly… I’m serving on localhost because it is within docker/kubernetes.

I’d be interested in the expected behaviour of if there is something I can put at the top of the server block to check for the port with a matcher and then skip the rest and serve the admin API.

Mohammed90 · June 4, 2025, 3:39pm

What’s the config you ran? That seems like an issue in FrankenPHP, though

matt · June 4, 2025, 8:40pm

How can we reproduce the behavior?

silverbackdan · June 5, 2025, 9:17am

Hi guys, sorry these reply notifications went to my junk.

The project is here:

The Caddyfile is here:

github.com/components-web-app/components-web-app

api/frankenphp/Caddyfile

main

# https://www.ietf.org/archive/id/draft-nottingham-http-invalidation-01.txt
{
	{$CADDY_GLOBAL_CONFIG}

    admin :2019

    cache {
        api {
			souin
		}

		cdn {
			{$CADDY_CACHE_CDN_CONFIG:strategy hard}
		}

		key {
		    hide
			template "CWA-{http.request.method}-{http.request.host}-{http.request.uri.path}-{http.request.uri.query}-{http.request.header.accept}-{http.request.cookie.api_component}"
		}

This file has been truncated. show original

And you should be able to reproduce by running docker compose up php - then try a curl command to port 2019. It seemed intermittent. But when I changed the Caddyfile once the application was running, changed the admin port away from 2019 and then back again it started working.

Any environment configs are in compose:
Namely the server name for the block which I don’t think is changed anywhere else:

github.com/components-web-app/components-web-app

compose.yaml

main


      
          services:
            php:
              image: ${IMAGES_PREFIX:-}app-php
              depends_on:
                - database
              restart: unless-stopped
              environment:
                APP_UPSTREAM: app:3000
                SERVER_NAME: ${SERVER_NAME:-localhost}, php.local:80, php.local:443
                # Will be needed for Server-side/internal loads to generate the doc headers
                BROWSER_SERVER_NAME: ${BROWSER_SERVER_NAME:-localhost}
                # CHANGES TO ENV TO MAP CADDY_MERCURE_JWT_SECRET NOW INSTEAD OF MERCURE_PUBLISHER_JWT_KEY
                MERCURE_PUBLISHER_JWT_KEY: ${CADDY_MERCURE_JWT_SECRET:-!ChangeThisMercureHubJWTSecretKey!}
                # CHANGES TO ENV TO MAP CADDY_MERCURE_JWT_SECRET NOW INSTEAD OF MERCURE_SUBSCRIBER_JWT_KEY
                MERCURE_SUBSCRIBER_JWT_KEY: ${CADDY_MERCURE_JWT_SECRET:-!ChangeThisMercureHubJWTSecretKey!}
                # CHANGES TO ENV TO MAP CADDY_MERCURE_CORS_ORIGIN NOW INSTEAD OF MERCURE_CORS_ORIGIN
                MERCURE_CORS_ORIGIN: ${CADDY_MERCURE_CORS_ORIGIN:-https://localhost}
                TRUSTED_PROXIES: ${TRUSTED_PROXIES:-127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16}
                TRUSTED_HOSTS: ${TRUSTED_HOSTS:-^${SERVER_NAME:-example\.com|localhost}|php$$}

I don’t think you will need the override file. I just adjusted it so 2019 is exposed to the local machine by default too.

In the dockerfile the custom build is here:

github.com/components-web-app/components-web-app

api/Dockerfile

main


      
          RUN xcaddy build \
              --output /usr/local/bin/frankenphp \
              --with github.com/dunglas/frankenphp/caddy \
              --with github.com/dunglas/caddy-cbrotli \
              --with github.com/dunglas/mercure/caddy \
              --with github.com/dunglas/mercure/caddy \
              --with github.com/dunglas/vulcain/caddy \
              --with github.com/darkweak/souin/plugins/caddy@v1.7.6 \
              --with github.com/darkweak/storages/otter/caddy \
              --with github.com/darkweak/storages/badger/caddy \
              --with github.com/darkweak/storages/nuts/caddy
              # --with github.com/darkweak/storages/go-redis/caddy \

I’ve had quite a few things on so if you’d like to leave it with me to test and re-test later to try and find a consistent reproduction please do let me know.

I guess my first question was is this actually a bug or is there a known way to prevent a server block being run before Caddy will run the admin on 2019, and should this config for the server block be responding to port 2019 if the name localhost is being used without additional ports or should it just be listening to 80 and 443? With this information, I could be able to do more digging.

silverbackdan · June 5, 2025, 10:06am

By the way, I’m versioning Souin only because the recent patch removed the endpoint without going via Caddy API/Admin port. And this is why I discovered the issues I was having.