Confusing migrating FPM config from Apache


1. The problem I’m having:

Currently we have a PHP application running using containerised php-fpm. Access for HTTP clients is provided via containerised Apache configured as

<Location /health.php>
        SetHandler proxy:fcgi://mvc-api:9000/app/health.php

<Location "/api/v1">
        SetHandler proxy:fcgi://mvc-api:9000/app/entrypoint.php

SetHandler proxy:fcgi://mvc-api:9000/app/legacy/entrypoint.php
  • Requests to /api/v1/foo would be run by /app/entrypoint.php with the PATH_INFO of /api/v1/foo.
  • Requests to /api/bar would be run by /app/legacy/entrypoint.php with the PATH_INFO of /api/bar.

I am unable to understand how to express this in terms of Caddy configurations.

2. Error messages and/or full log output:

Note: this is still in the local test stages, so I have limited ability to provide public reproducers. However, I suspect this just a disconnect from my outdated memory of the FastCGI protocol and the Caddy docs.

The symptom is requests never being forwarded to the FastCGI server, and it is seen under a number of configs. I did get one request to proxy…but it turns out I had two copies of Caddy running (too many terminals) so I’m not sure what the known good configuration was.

$ caddy run --config kube/base/Caddyfile
2023/04/04 18:32:59.904 INFO    using provided configuration    {"config_file": "kube/base/Caddyfile", "config_adapter": ""}
2023/04/04 18:32:59.905 WARN    Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies    {"adapter": "caddyfile", "file": "kube/base/Caddyfile", "line": 5}
2023/04/04 18:32:59.907 INFO    admin   admin endpoint started  {"address": "localhost:2019", "enforce_origin": false, "origins": ["//", "//localhost:2019", "//[::1]:2019"]}
2023/04/04 18:32:59.908 INFO    tls.cache.maintenance   started background certificate maintenance      {"cache": "0xc00090e000"}
2023/04/04 18:32:59.909 INFO    tls     cleaning storage unit   {"description": "FileStorage:/Users/benedict.harcourt/Library/Application Support/Caddy"}
2023/04/04 18:32:59.909 DEBUG   http    starting server loop    {"address": "[::]:8080", "tls": false, "http3": false}
2023/04/04 18:32:59.909 INFO    tls     finished cleaning storage units
2023/04/04 18:32:59.909 INFO    http.log        server running  {"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2023/04/04 18:32:59.910 INFO    autosaved config (load with --resume flag)      {"file": "/Users/benedict.harcourt/Library/Application Support/Caddy/autosave.json"}
2023/04/04 18:32:59.910 INFO    serving initial configuration
^C2023/04/04 18:33:11.600       INFO    shutting down   {"signal": "SIGINT"}
2023/04/04 18:33:11.600 WARN    exiting; byeee!! 👋     {"signal": "SIGINT"}
2023/04/04 18:33:11.600 DEBUG   http    servers shutting down with eternal grace period
2023/04/04 18:33:11.600 INFO    tls.cache.maintenance   stopped background certificate maintenance      {"cache": "0xc00090e000"}
2023/04/04 18:33:11.600 INFO    admin   stopped previous server {"address": "localhost:2019"}
2023/04/04 18:33:11.600 INFO    shutdown complete       {"signal": "SIGINT", "exit_code": 0}

There’s no errors anywhere – just no meaningful response

$ curl -v http://localhost:8080/api/v1/foo
*   Trying
* Connected to localhost ( port 8080 (#0)
> GET /api/v1/foo HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.79.1
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: Caddy
< Date: Tue, 04 Apr 2023 18:58:22 GMT
< Content-Length: 0
* Connection #0 to host localhost left intact

3. Caddy version:

4. How I installed and ran Caddy:

Caddy is installed via Brew on an Intel Macbook

$ caddy version  
v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=


$ caddy run --config kube/base/Caddyfile

d. My complete Caddy config:

Some configs I tried include the following. There’s also others that didn’t make it into version control as I was working


:8080 {
	handle /* {
	  php_fastcgi localhost:9000 {
	    root /app/public/index.php
:8080 {

	root * /app/public
	encode zstd gzip
	php_fastcgi localhost:9000
:8080 {

		php_fastcgi /api/v1/foo {
			root /app/public/index.php

		php_fastcgi /api/v1/bar localhost:9000/app/public/index.php {
			root /app/public/index.php
			split /

If your entrypoint isn’t /index.php, then you need to override the try_files option in php_fastcgi:

:8080 {
	root * /app/public
	encode zstd gzip
	php_fastcgi localhost:9000 {
		try_files {path} {path}/ /entrypoint.php

The file needs to exist on disk and be accessible by Caddy for it to work. Make sure that /app/public is mounted in your Caddy container as well.

Thank you for the help!

It was indeed the combination of the files not being visible to Caddy and the try_files, and I have a working version. <3

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