Caddy 2 codeigniter not working

1. Caddy version (caddy version):

caddy 2.3.0

2. How I run Caddy:

sytemctl start caddy

a. System environment:


b. Command:

systemctl reload caddy
systemctl restart caddy
systemctl status caddy

c. Service/unit/compose file:

# caddy.service
# For using Caddy with a config file.
# Make sure the ExecStart and ExecReload commands are correct
# for your installation.
# See for instructions.
# WARNING: This service does not use the --resume flag, so if you
# use the API to make changes, they will be overwritten by the
# Caddyfile next time the service is restarted. If you intend to
# use Caddy's API to configure it, add the --resume flag to the
# `caddy run` command or use the caddy-api.service file instead.



ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile


d. My complete Caddyfile or JSON config:

paste config here, replacing this text
use `caddy fmt` to make it readable
DO NOT REDACT anything except credentials
or helpers will be sad

3. The problem I’m having:

Routes are not working, always shows the default route for any url for example /process/hi should display the controller: pages, method: hi but it displays the default route, i think there is maybe something wrong with my try_files but even when i add {query} behind index.php it doesn’t work

4. Error messages and/or full log output:

 caddy.service - Caddy
     Loaded: loaded (/lib/systemd/system/caddy.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2021-01-31 22:55:42 CET; 1 day 14h ago
   Main PID: 60140 (caddy)
      Tasks: 11 (limit: 14275)
     Memory: 27.8M
     CGroup: /system.slice/caddy.service
             └─60140 /usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.4381948,"logger":"tls.cache.maintenance","msg":"certificate expires soon; q>
Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.43853,"logger":"tls.cache.maintenance","msg":"attempting certificate renewa>
Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.4396544,"logger":"tls.renew","msg":"acquiring lock","identifier":"45.15.143>
Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.439948,"logger":"tls.renew","msg":"lock acquired","identifier":">
Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.4405932,"logger":"tls.renew","msg":"renewing certificate","identifier":"45.>
Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.4430285,"logger":"tls.renew","msg":"certificate renewed successfully","iden>
Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.4431002,"logger":"tls.renew","msg":"releasing lock","identifier":"45.15.143>
Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.4432263,"logger":"tls","msg":"reloading managed certificate","identifiers":>
Feb 02 07:45:42 caddy[60140]: {"level":"warn","ts":1612248342.4444888,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for >
Feb 02 07:45:42 caddy[60140]: {"level":"info","ts":1612248342.444586,"logger":"tls.cache","msg":"replaced certificate in cache","identifi>

5. What I already tried: {
encode zstd gzip
root *  /var/www/panels/panel
php_fastcgi unix//run/php/php7.4-fpm.sock
file_server browse
handle /process* {
  try_files  {path}/ /process/index.php

6. Links to relevant resources:

Okay - we’ll need to enable debug mode to see more details in the logs to see what’s going on with the try_files rewrites. Add this to the top of your Caddyfile, then reload Caddy.


Also, I recommend running caddy fmt to clean up the indentation in your config, it’s a bit messy as-is.

Once you’ve enabled debug mode, use this command to see all your logs, otherwise they’re truncated (see the > at the end of each line)

journalctl -u caddy --no-pager | less
1 Like


this is the error i get

Feb 02 20:25:12 caddy[81208]: {"level":"debug","ts":1612293912.4744046,"logger":"http.handlers.file_server","msg":"sanitized path join","site_root":"/var/www/panels/panel","request_path":"/process/hi","result":"/var/www/panels/panel/process/hi"}

there is no subfolder hi in the process folder everything should be handled using index.php

What that’s telling me is the rewrite from try_files never happened, if you didn’t see logs for that.

Are you sure that /var/www/panels/panel/process/index.php exists on disk?

That was indeed the problem i changed it but still got a problem

Feb 02 22:14:58 caddy[81208]: {"level":"debug","ts":1612300498.3319886,"logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"unix//run/php/php7.4-fpm.sock","request":{"remote_addr":"personalip:1199","proto":"HTTP/2.0","method":"GET","host":"","uri":"index.php","headers":{"Accept":["image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8"],"Sec-Gpc":["1"],"Referer":[""],"Accept-Encoding":["gzip, deflate, br"],"Cookie":["PHPSESSID=jghm9esgk4a1hq71d317ivirnc; real=ok; lng=nl; ci_session=1r4v7si5phdh9ool0rk38a7t3qmohcbs"],"X-Forwarded-For":["PERSONALIP"],"User-Agent":["Mozilla/5.0 (iPhone; CPU iPhone OS 13_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.2 Mobile/15E148 Safari/604.1"],"Sec-Fetch-Site":["same-origin"],"Sec-Fetch-Mode":["no-cors"],"Sec-Fetch-Dest":["image"],"Accept-Language":["en-US,en;q=0.9,nl;q=0.8"],"X-Forwarded-Proto":["https"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","proto_mutual":true,"server_name":""}},"duration":0.009752169,"headers":{"Cache-Control":["no-store, no-cache, must-revalidate"],"Pragma":["no-cache"],"Set-Cookie":["ci_session=l7uguncov8l9pke9o3rpfgm5fe95bgf9; expires=Wed, 03-Feb-2021 17:14:58 GMT; Max-Age=72000; path=/; HttpOnly"],"Content-Type":["text/html; charset=UTF-8"],"Expires":["Thu, 19 Nov 1981 08:52:00 GMT"]},"status":200}

That looks like a successful response :thinking: what’s the problem?

The problem is the following:

404 - File Not Found
Controller or its method is not found: App\Controllers\Pages::itsmee

It seems to alway display the default controller and method for routes instead of the set route

What actual route is your site looking to handle? Is it /hi? Or is it /process/hi?

Its trying to handle /process/hi /process is a subfolder and /hi is the route

Okay, so I think you should actually be using handle_path instead of handle, which will strip the /process part from the URL before handling the request.

If that doesn’t work, then please post the fastcgi part of your Caddy logs. We’ll need to look at the value of PATH_INFO being passed to your app.

I did the following:


To clarify i also tried echo same result

This seems to be empty though no value returned

i will paste my route here

$routes->get('/hi', 'pages::hi');

this is the full info

PHP_SELF	/process/index.php
argv	-
argc	-
REQUEST_TIME	1612343267
REQUEST_TIME_FLOAT	1612343267.2434
DOCUMENT_ROOT	/var/www/panels/panel
HTTP_ACCEPT	text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
HTTP_ACCEPT_ENCODING	gzip, deflate, br
HTTP_ACCEPT_LANGUAGE	en-US,en;q=0.9,nl;q=0.8
HTTP_USER_AGENT	Mozilla/5.0 (iPhone; CPU iPhone OS 13_7 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.2 Mobile/15E148 Safari/604.1
SCRIPT_FILENAME	/var/www/panels/panel/process/index.php
SCRIPT_NAME	/process/index.php
REQUEST_URI	/process/hi


} {
        encode zstd gzip
        root * /var/www/panels/panel
        php_fastcgi unix//run/php/php7.4-fpm.sock
        file_server browse
        handle_path /process* {
                try_files {path}/ /process/index.php?{query}

Okay. This is kinda tricky actually.

I don’t have the time to debug this right now to figure out the right solution, but try this:

handle_path /process* {
	root * /var/www/panels/panel/process

Basically this will strip the /process path prefix, then change the site root to add /process, then the default php_fastcgi behaviour should apply, and it’ll rewrite to index.php but inside of the new root.

REQUEST_URI will still show /process/hi but you should see DOCUMENT_ROOT become /var/www/panels/panel/process and PATH_INFO filled with /hi. I hope.

If not, I’ll need to do a deeper dive on the code soon.

Document_root changed sadly PATH_INFO is still empty

Okay – sorry to take a while on this. Next thing to try, change your try_files to this:

	handle_path /process* {
		@try_files file {
			try_files {path}/ /process/index.php
			split_path .php
		rewrite @try_files {http.matchers.file.relative}

And if that doesn’t work, maybe try with handle instead of handle_path. I’m not certain how that’ll behave.

As an explanation, look at the expanded form of php_fastcgi and try_files (both are shortcuts to longer bits of config):

The try_files that’s built into php_fastcgi has split_path parameter. What that does it tell the file matcher to remember the bit after the path that was split away after the rewrite, so that the fastcgi transport can grab it later. There’s a bunch of history behind it that you can read here… if you care:

Basically you’re running into an edgecase in the default behaviour with subpaths.

I do have a particular change in mind that might fix the default behaviour in php_fastcgi for that to work, but I’m not certain I want to do it due to performance considerations. It would involve implementing a new mode for the file matcher which would try to look at up to N path segments for index files in their directories, before falling back to /index.php.

1 Like

Sadly this hasn’t fixed the problem yet tried both handle & handle_path

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