Debug messages appearing in console


(Richard Stupek) #1

Is there any way to reduce the number of messages logged by caddy (coming through the go http library) like the following:
018/05/29 14:28:58 http: TLS handshake error from 76.19.42.168:51214: tls: client offered an unsupported, maximum protocol version of 300
2018/05/29 14:29:02 http: TLS handshake error from 82.13.130.54:48256: EOF
2018/05/29 14:29:02 http: TLS handshake error from 159.45.197.15:59662: hostname ‘’ does not qualify for certificate
2018/05/29 14:29:09 http: TLS handshake error from 180.76.15.163:26196: tls: unsupported SSLv2 handshake received
29/May/2018:14:29:15 -0500 [ERROR 502 /storeOrders/default] context canceled
2018/05/29 14:29:29 http: TLS handshake error from 194.63.141.238:46732: hostname ‘1.1.1.1’ does not qualify for certificate
2018/05/29 14:29:43 http: TLS handshake error from 5.62.50.13:22843: tls: client offered an unsupported, maximum protocol version of 301


(Matthew Fay) #2

Not that I’m aware of. You can enable/disable the errors and access logging overall, and define a log format, but I don’t believe it’s possible to subscribe only to specific kinds of messages.

Given the prevalence of log aggregation and filtering tools, I can’t say I’ve personally ever seen a need to filter logs via Caddy itself.


(Richard Stupek) #3

the errors appear to be “debug” related and I’ve never seen a program that didn’t have logging levels. I guess I’ll dig through the source and see what golang provides


(Matthew Fay) #4

I wouldn’t call them debug level, they’re access attempts - failed access attempts, specifically - although they’re not sent to the access logs, but rather the process logs.

Client tried to connect with TLS1.0, which is deprecated and disabled in the default Caddy configuration.

Client read our TLS data and sent nothing back.

This error occurs in the On-Demand TLS functionality when Caddy determines that it won’t be able to get a certificate to satisfy a valid TLS connection for the given hostname (which is empty - HTTPS attempt with no SNI, probably?)

Another access attempt with an old, outdated protocol.

This is a standard error indicating that one of Caddy’s peers (upstream or downstream) ended the connection.

Same issue as the above On-Demand TLS one. Strange that someone is trying to get 1.1.1.1 from your server, though.

Same as version 300, except this is TLS1.1, also deprecated and disabled by default.

All of them (except for the 502) are recorded to the process logging target, so you could remove the -log flag from your Caddy starting flags and you won’t get any more.