Perhaps a non-issue but hoping somebody can advise about some behaviour I’m seeing with a Windows machine running Caddy v2.0.
I’m using Caddy as a reverse proxy for ~10 sites, however I’ve recently noticed that attempts to browse to my server via either it’s public IP address, or a hostname that points to it (but has no site defined in Caddy) returns an SSL error. The sites that are defined work perfectly fine, so it’s not a huge issue. I’m just wondering about the exception handling for somebody that might hit my server some other way.
Is this expected behaviour? I’m sure it used to do something more graceful when running v1?
1. Caddy version (caddy version):
PS C:\Caddy> .\caddy version
v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=
2. How I run Caddy:
As a Windows service, using NSSM
a. System environment:
Windows 10 v10.0.18362
b. Command:
nssm start caddy
c. Service/unit/compose file:
N/A
d. My complete Caddyfile or JSON config:
Apologies for domain obfuscation but not really relevant to the issue.
# Site 1
site.1 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://localhost:8080 {
}
}
# Site 2
site.2 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://localhost:7878 {
header_up X-Real-IP {http.request.remote}
header_up X-Forwarded-Port {http.request.port}
header_up X-Forwarded-Proto {http.request.scheme}
header_up X-Forwarded-Ssl {on}
}
}
# Site 3
site.3 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://localhost:8989 {
header_up X-Real-IP {http.request.remote}
header_up X-Forwarded-Port {http.request.port}
header_up X-Forwarded-Proto {http.request.scheme}
header_up X-Forwarded-Ssl {on}
}
}
# Site 4
site.4 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://localhost:5000 {
}
}
# Site 5
site.5 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://localhost:8181 {
header_up X-Real-IP {http.request.remote}
header_up X-Forwarded-Port {http.request.port}
header_up X-Forwarded-Proto {http.request.scheme}
header_up X-Forwarded-Ssl {on}
}
}
# Site 6
site.6 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy https://localhost:4443 {
transport http {
tls
tls_insecure_skip_verify
read_buffer 8192
}
}
}
# Site 7
site.7 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://192.168.1.200 {
}
rewrite / /admin
}
# Site 8
site.8 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://localhost:32400 {
}
}
# Site 9
site.9 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://192.168.1.200:8020 {
}
}
# Site 10
site.10 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://192.168.1.200:8050 {
}
}
# Site 11
site.11 {
encode gzip
log {
output file C:/Caddy/logs/caddy.log
format single_field common_log
}
reverse_proxy http://192.168.1.200:8060 {
}
rewrite / /cgi-bin/smokeping.cgi{uri}
}
# www redirect
www.site.12 {
redir https://site.12
}
3. The problem I’m having:
If somebody hits my server with an HTTP request using either my public IP address or some other domain that points to my IP but isn’t defined in my Caddy File, then the request seems to be upgraded to HTTPS and the browser returns an HTTPS error. I’m almost certain before I upgraded to v2.0 that the web server handled this gracefully and returned a ‘Site doesn’t exist at this address’ error or something similar?
4. Error messages and/or full log output:
e.g. in Edge Chromium - ERR_SSL_PROTOCOL_ERROR
5. What I already tried:
Not much, as I don’t really know where to start. Unsure how to extract logging from Windows machine for an undefined site?
6. Links to relevant resources:
N/A
