HTTP on port 443

Help
1

1. The problem I’m having:

I’m using Caddy behind a load balancer that strips HTTPS from incoming requests before it passes it to the server. (This infrastructure is managed by my uni’s IT team and cannot be changed).

I tried specified a listening address using http://caddy-test.uqcloud.net:443 but this did not work. Listening only on port 80 does, but it prevents browsers that upgrade to HTTPS automatically (like Fx with HTTPS-everywhere enabled) from being able to connect.

Caddy is run as the last step in a script that generates files and then uses the file_server to allow the user to download the artifacts.

2. Error messages and/or full log output:

2025/03/28 01:42:05.646 INFO     using adjacent Caddyfile
Error: adapting config using caddyfile: server block 0, key 1 (http://caddy-test.uqcloud.net:443): determining listener address: [http://caddy-test.uqcloud.net:443] scheme and port violate convention

3. Caddy version:

# caddy version
v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=

4. How I installed and ran Caddy:

I installed Caddy by following the instructions for Debian, Ubuntu, Raspbian on Install — Caddy Documentation. I picked the stable release channel.

a. System environment:

Debian 12, x86-64, running from CLI.

b. Command:

$ caddy run

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

{
        servers {
                protocols h1 h2
                trusted_proxies static 172.23.83.250/31
        }
        auto_https off
}

http://caddy-test.uqcloud.net:80, http://caddy-test.uqcloud.net:443 {
        file_server browse
}

5. Links to relevant resources:

The documentation for the containers on which it is running specify that it is necessary to listen for regular HTTP on both port 80 and 443, and provide instructions for Apache2.

First, when the EAIT loadbalancers direct HTTP requests to your zone, they make a number of changes to the request. They inject some additional headers (e.g. X-Real-IP so you can see the actual client IP address), and they also strip TLS/SSL from HTTPS requests, relaying them as plain HTTP.

This means that your zone has to be configured to listen for plain HTTP requests without TLS/SSL on both ports 80 and 443. You should also configure your web server to trust and process the headers such as X-Real-IP where possible, to keep your logs accurate.

docs

2

This is a bit out of my realm, but figured I’d chime in.

If you control the caddy-test.uqcloud.net domain, I think you may be able to find a way to temporarily serve an HTTPS response to try and reset any HSTS policies.

If not, I think the only other solutions is to tell anyone attempting to access it that they need to explicitly use http:// or temporarily adjust browser settings to allow HTTP.

3

I don’t really control the domain unfortunately - the subdomains get provisioned by the system automatically based on the container name.

For now, I’ll specify the use of http. I was just hoping there was something in the docs I had missed that allows overriding the conventions.

1 Like
4 
{
	http_port 443
	auto_https off
}

http://localhost:80, localhost:443 {
	respond "Alive"
}

$ curl http://localhost:80
Alive

$ curl http://localhost:443
Alive
3 Likes
5

Perfect - thank you very much for your help!

1 Like