Recommended way to close connection on requests to IP?

1. The problem I’m having:

On a server I have increasing traffic of bots scanning the server by performing requests to http://<IP-Address/.
Caddy responds with a 308 redirect to https://<IP-Address/.

I wonder if there is a recommended way to

  • ignore requests to the raw IP (perfect)
  • perform a connection reset below the application layer (like NGINX’s 444) (ok)
  • respond w/out a location redirect (at least)

In that particular case I don’t want to return 403 code or the like as I see it more in the way of “it’s not forbidden, it’s just not configured”.

2. Error messages and/or full log output:

curl -I

HTTP/1.1 308 Permanent Redirect
Connection: close
Server: Caddy
Date: Wed, 26 Apr 2023 08:25:49 GMT

3. Caddy version:


4. How I installed and ran Caddy:

a. System environment:

d. My complete Caddy config:

I just configured domain blocks. {

I am not sure if this is possible, because the server can’t know the request is “to” the “raw IP” until it reads the Host header. To truly ignore the request would involve ignoring all requests, essentially turning off the server.

But what you can do is match on the Host header if it contains your IP and then abort the request: {

That closes the connection uncleanly and doesn’t even write an HTTP response. I’d say it’s somewhere between your “perfect” and “ok” solutions.

Anyway, you could try that.

That seems to work (tested locally): Both curl and wget fail due to the abort, e.g.

* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

I added it like this:, {

The runtime.log is empty for the http-request and only logs the tls_get_certificate event.

I’ll give it a try on production.

Thank you Matt!

1 Like

This doesn’t make sense – Caddy won’t have a certificate for that hostname anyways so the TLS handshake will never succeed, so HTTP routing never happens. You should only keep the http:// site address.

1 Like

In my local dev server I previously had a line, {

so it created a certificate. I think. At least this is what I read out of the logs (DEBUG tls.handshake choosing certificate {"identifier": "", "num_choices": 1}).
Not on the prod server.

1 Like

IP addresses are not eligible for publically trusted certs. You would’ve only had a cert if you used tls internal.

Generally true, but to be nuanced in case a future searcher finds this thread: they are eligible, but only some CAs offer them and only in certain ways (i.e. very few allow ACME to issue IP certs).

I’m pretty sure Caddy will issue its own self-signed cert for IP addresses, without needing to specify tls internal.

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