How to drop connection

I’m using caddy v2 as a reverse proxy for containers, and my host has many DNS aliases. I want to have a way to drop the connection for requests to DNS hostnames that are not in the caddyfile.

It seems that nginx has a specific magic trick to do it - nginx: How to drop connections for a location - makandra dev

(basically, respond with a status code that is invalid, and the socket is closed)

seeing How to drop request completely based on IP , I’m assuming this is not currently possible

so I wonder - would it make sense to have a cfg like:

respond * {

as a fallback when no matchers have matched?

Well, if you’re using TLS, then Caddy will respond with a TLS handshake failure if it didn’t have an appropriate certificate. I assume the connection is closed automatically in those situations.

So it depends on how your Caddyfile is structured. Could you please share it, so we can discuss how that would look?

1 Like

ah, I use wildcard certs, so that too doesn’t work.

My caddyfile is dynamic - its generated from container labels - but basically - I want to have a way to specify “if we match this” (or “if no match has been made”) close.

I’m aware that this isn’t identical to what would happen if there was nothing listening to the port, but its a start.

	debug true
(dns_api_gandi) {
	tls {
		issuer acme {
			dns gandi {env.GANDIV5_API_KEY}
		issuer internal

* {
	@testing_loc_alho_st {
	import dns_api_gandi
	route @testing_loc_alho_st {
		respond Testing

        # <<<<<< HERE is where I'd like to say if nothing matched so far, just close

If I understand you correctly, Sven, then what you suggested:

respond {

should do the trick. (I omitted the matcher, which you can add based on your requirements.)

I was pretty sure that’s what I tried first - so I re-ran it, and this gives me

[ERROR] Removing invalid block: parsing caddyfile tokens for ‘respond’: Caddyfile:135 - Error during parsing: Wrong argument count or unexpected line ending after ‘respond’

* {
	@testing_loc_alho_st {
	import dns_api_gandi
	route @testing_loc_alho_st {
		respond Testing
	respond {

yup, pushing boundaries :slight_smile:

Oh, right, a status code or response body is required. So something like respond 4xx should work (choose a status code of your choice).

sadly, no

dow184@township-sl:~/src/caddy$ curl -v
*   Trying
* Connected to ( port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=*
*  start date: Jan 13 02:28:11 2021 GMT
*  expire date: Apr 13 02:28:11 2021 GMT
*  subjectAltName: host "" matched cert's "*"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5650d865bdf0)
> GET / HTTP/2
> Host:
> user-agent: curl/7.68.0
> accept: */*
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 444 
< server: Caddy
< content-length: 0
< date: Wed, 20 Jan 2021 00:42:02 GMT
* Connection #0 to host left intact

I want it to not reply especially with some form of http status code / http headers

just to close the socket.

I see… you will want to track this issue then:

1 Like

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