1. Caddy version (caddy version): Caddy v1.0.5
2. How I run Caddy:
Built from source
package main
import (
"github.com/caddyserver/caddy/caddy/caddymain"
_ "github.com/caddyserver/forwardproxy"
)
func main() {
caddymain.EnableTelemetry = false
caddymain.Run()
}
a. System environment:
Raspberry Pi 4B Raspbian armv7
b. Command:
Caddy is run from the service, specified below.
c. Service/unit/compose file:
[Unit]
Description=Caddy HTTP/2 web server
Documentation=https://caddyserver.com/docs
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service
[Service]
Restart=on-abnormal
LimitNOFILE=16384
EnvironmentFile=/etc/default/caddy
ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=${CONFIG_FILE} -root=${ROOT_DIR}
ExecReload=/bin/kill -USR1 $MAINPID
KillMode=mixed
KillSignal=SIGQUIT
TimeoutStopSec=5s
[Install]
WantedBy=multi-user.target
d. My complete Caddyfile or JSON config:
exportcloud.net {
tls test@isotope.dev
root /var/www
errors {
403 /var/www/403.html
}
forwardproxy {
hide_ip
hide_via
basicauth admin xxxxxxxxxx
acl {
deny *.isotope.dev
}
}
}
3. The problem I’m having:
I’m trying to use an access control list (ACL) which in the config is specified to block all isotope.dev pages. This works, however, previously when accessing a blocked site/ip the the server would respond with 403 and show the error file specified in the caddyfile. Unfortunatly instead of this, the proxy seemingly blocks the entire site from ever loading giving an error like ERR_TUNNEL_CONNECTION_FAILED in Chrome or Failed reading proxy response: Success in wget (terminal).
4. Error messages and/or full log output:
● caddy.service - Caddy HTTP/2 web server
Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-09-25 20:15:08 BST; 1h 10min ago
Docs: https://caddyserver.com/docs
Process: 13991 ExecReload=/bin/kill -USR1 $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 13814 (caddy)
Tasks: 13 (limit: 4915)
CGroup: /system.slice/caddy.service
└─13814 /usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/caddyfile -root=/var/www
Sep 25 21:15:26 0cf caddy[13814]: [ERROR 0 ] http2: stream closed
Sep 25 21:15:44 0cf caddy[13814]: 2020/09/25 21:15:44 [INFO][cache:0x3297900] Scanning for stale OCSP staples
Sep 25 21:15:44 0cf caddy[13814]: 2020/09/25 21:15:44 [INFO][cache:0x3297900] Done checking OCSP staples
Sep 25 21:17:30 0cf caddy[13814]: 2020/09/25 21:17:30 http: TLS handshake error from 10.0.0.1:36418: tls: first record does not look like a TLS handshake
Sep 25 21:17:31 0cf caddy[13814]: 2020/09/25 21:17:31 http: TLS handshake error from 10.0.0.1:36420: tls: first record does not look like a TLS handshake
Sep 25 21:21:43 0cf caddy[13814]: 2020/09/25 21:21:43 [INFO][cache:0x33c6e80] Scanning for stale OCSP staples
Sep 25 21:21:43 0cf caddy[13814]: 2020/09/25 21:21:43 [INFO][cache:0x33c6e80] Done checking OCSP staples
Sep 25 21:22:59 0cf caddy[13814]: [ERROR 0 ] read tcp 10.0.0.40:59630->23.37.117.167:443: read: connection reset by peer
Sep 25 21:22:59 0cf caddy[13814]: [ERROR 0 ] read tcp 10.0.0.40:59638->23.37.117.167:443: read: connection reset by peer
Sep 25 21:26:06 0cf caddy[13814]: 2020/09/25 21:26:06 http: TLS handshake error from 10.0.0.1:36470: tls: first record does not look like a TLS handshake
5. What I already tried:
I’ve tried different domains and tried using the terminal as well as a browser to see if there is something client side that’s wrong and I cant find anything.