Probleme configuring second website on a caddy web server

1. The problem I’m having:

I’m trying to run two sites on the same caddy server : and

I’ve tested my DNS configuration separately and it works properly for both domain and subdomain.

Caddy is run by the caddy user of the caddy group.
The directories of both websites are configured exactly the same, including access, reader, write and execute permissions.

2. Error messages and/or full log output:

The first site,, works properly both in HTML and PHP.
The second one,, return 403 for the index.html file et 404 for info.php

3. Caddy version: v2.7.6

4. How I installed and ran Caddy:

I followed the official Rocky Linux tutorial for caddy installation : Caddy Web Server - Documentation

a. System environment:

Rocky Linux 9.3

b. Command:

sudo systemctl start caddy

c. Service/unit/compose file:

d. My complete Caddy config:

# The Caddyfile is an easy way to configure your Caddy web server.

# The configuration below serves a welcome page over HTTP on port 80.  To use
# your own domain name with automatic HTTPS, ensure your A/AAAA DNS record is
# pointing to this machine's public IP, then replace `http://` with your domain
# name.  Refer to the documentation for full instructions on the address
# specification.
# Domaine {
	# Set this path to your site's directory.
	root * /srv/www/

	# Enable the static file server.

	# Another common task is to set up a reverse proxy:
	# reverse_proxy localhost:8080

	# Or serve a PHP site through php-fpm:

	# Refer to the directive documentation for more options.

# Redirection www vers nu {

# domaine {
	root * /srv/www/
	log { 
		output file /var/log/caddy/subdomain.domain01.log

# As an alternative to editing the above site block, you can add your own site
# block files in the Caddyfile.d directory, and they will be included as long
# as they use the .caddyfile extension.
# import Caddyfile.d/*.caddyfile

5. Links to relevant resources:

Check the file/directory permissions. Make sure the caddy user can read those files.

Show ls -la for /srv/www/ and /srv/www/

Here are the results :

[rocky@vps ~]$ ls -la /srv/www/
total 0
drwxr-xr-x. 3 caddy caddy    20 Feb  6 19:51 .
drwxrwxr-x. 4 rocky sftpteam 54 Feb  7 04:16 ..
drwxr-xr-x. 2 caddy caddy    67 Feb 12 22:14 htdocs

[rocky@vps ~]$ ls -la /srv/www/
total 164
drwxr-xr-x. 2 caddy caddy     67 Feb 12 22:14 .
drwxr-xr-x. 3 caddy caddy     20 Feb  6 19:51 ..
-rw-r--r--. 1 caddy caddy     13 Feb 12 22:14 index.html
-rw-r--r--. 1 caddy caddy     20 Feb 12 22:14 info.php

Hmm, that does seem fine.

Add this to the top of your Caddyfile:


Then make a request with curl -v, show that output, then show your Caddy logs (the command to use to see your logs can be found here Keep Caddy Running — Caddy Documentation)

Does Rocky Linux have SELinux enabled? Maybe there’s some SELinux rule preventing access of those files?

Here is the results :

[rocky@vps ~]$ curl -v
*   Trying
* Connected to ( port 80 (#0)
> GET / HTTP/1.1
> Host:
> User-Agent: curl/7.76.1
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location:
< Server: Caddy
< Date: Tue, 13 Feb 2024 12:26:39 GMT
< Content-Length: 0
* Closing connection 0

The log show :

{"level":"info","ts":1707827199.2037675,"logger":"http.log.access.log0","msg":"handled request","request":{"remote_ip":"111.22.333.44","remote_port":"40896","client_ip":"111.22.333.44","proto":"HTTP/1.1","method":"GET","host":"","uri":"/","headers":{"User-Agent":["curl/7.76.1"],"Accept":["*/*"]}},"bytes_read":0,"user_id":"","duration":0.00003663,"size":0,"status":308,"resp_headers":{"Content-Type":[],"Server":["Caddy"],"Connection":["close"],"Location":[""]}}

and :

[rocky@vps ~]$ journalctl -u caddy --no-pager | less +G
Feb 13 12:26:37 caddy[341324]: {"level":"debug","ts":1707827197.545008,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":""}
Feb 13 12:26:37 caddy[341324]: {"level":"debug","ts":1707827197.5450168,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*"}
Feb 13 12:26:37 caddy[341324]: {"level":"debug","ts":1707827197.5450208,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.*.info"}
Feb 13 12:26:37 caddy[341324]: {"level":"debug","ts":1707827197.5450249,"logger":"tls.handshake","msg":"no matching certificates and no custom selection logic","identifier":"*.*.*"}
Feb 13 12:26:37 caddy[341324]: {"level":"debug","ts":1707827197.5450325,"logger":"tls.handshake","msg":"no certificate matching TLS ClientHello","remote_ip":"","remote_port":"40986","server_name":"","remote":"","identifier":"","cipher_suites":[52392,52393,49199,49200,49195,49196,49171,49161,49172,49162,156,157,47,53,49170,10],"cert_cache_fill":0.0003,"load_or_obtain_if_necessary":true,"on_demand":false}
Feb 13 12:26:37 caddy[341324]: {"level":"debug","ts":1707827197.545111,"logger":"http.stdlib","msg":"http: TLS handshake error from no certificate available for ''"}

Yes SELinux is enabled…

That’s an HTTP request, so it just serves the HTTP->HTTPS redirect (the Location header is a redirect). Try curl -v instead.

Then it’s quite possible SELinux rules are blocking access to the files.

You could go through these steps to debug SELinux issues:

Before I read your answer I tried to disabled SELinux and then my both site works fine.

So probably it comes from SELinux,

Thanks for your help !

1 Like

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