Lots of requests since registering a package at `caddyserver.com/account/register-package`

[gucci-on-fleek]

I've recently registered my first Caddy package at caddyserver.com/account/register-package, and ever since then, I've been getting >10k requests per day from a single IP address, which accounts for >80% of my total requests:

$ jq 'select(.request.remote_ip == "2604:a880:2:d0::17d:6001").ts' ~web/caddy/logs/access.log > caddy.log

$ wc --lines caddy.log
35942 caddy.log

$ jq '.ts' ~web/caddy/logs/access.log | wc --lines
42610

$ expr 100 \* 35942 / 42610
84

$ date --date="@$(head -1 caddy.log)" --rfc-2822 --utc
Sun, 23 Nov 2025 12:23:03 +0000

$ date --date="@$(tail -1 caddy.log)" --rfc-2822 --utc
Wed, 26 Nov 2025 01:11:23 +0000

None of the requests use a descriptive User-Agent, and there's no reverse DNS set up:

$ jq 'select(.request.remote_ip == "2604:a880:2:d0::17d:6001").request.headers["User-Agent"][0]' ~web/caddy/logs/access.log | sort | uniq --count 
  36019 "Go-http-client/2.0"

$ dig +nostats -x 2604:a880:2:d0::17d:6001
; <<>> DiG 9.21.14 <<>> +nostats -x 2604:a880:2:d0::17d:6001
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53430
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;1.0.0.6.d.7.1.0.0.0.0.0.0.0.0.0.0.d.0.0.2.0.0.0.0.8.8.a.4.0.6.2.ip6.arpa. IN PTR

;; AUTHORITY SECTION:
1.0.0.6.d.7.1.0.0.0.0.0.0.0.0.0.0.d.0.0.2.0.0.0.0.8.8.a.4.0.6.2.ip6.arpa. 1399 IN SOA ns1.digitalocean.com. hostmaster.1.0.0.6.d.7.1.0.0.0.0.0.0.0.0.0.0.d.0.0.2.0.0.0.0.8.8.a.4.0.6.2.ip6.arpa. 1594762015 10800 3600 604800 1800

$ whois 2604:a880:2:d0::17d:6001
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#


NetRange:       2604:A880:: - 2604:A880:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
CIDR:           2604:A880::/32
NetName:        DIGITALOCEAN
NetHandle:      NET6-2604-A880-1
Parent:         NET6-2600 (NET6-2600-1)
NetType:        Direct Allocation
OriginAS:       
Organization:   DigitalOcean, LLC (DO-13)
RegDate:        2013-04-11
Updated:        2013-04-11
Comment:        Routing and Peering Policy can be found at https://www.as14061.net
Comment:        
Comment:        Please submit abuse reports at https://www.digitalocean.com/company/contact/#abuse
Ref:            https://rdap.arin.net/registry/ip/2604:A880::



OrgName:        DigitalOcean, LLC
OrgId:          DO-13
Address:        105 Edgeview Drive, Suite 425
City:           Broomfield
StateProv:      CO
PostalCode:     80021
Country:        US
RegDate:        2012-05-14
Updated:        2025-04-11
Ref:            https://rdap.arin.net/registry/entity/DO-13


OrgAbuseHandle: DIGIT19-ARIN
OrgAbuseName:   DigitalOcean Abuse
OrgAbusePhone:  +1-646-827-4366 
OrgAbuseEmail:  abuse@digitalocean.com
OrgAbuseRef:    https://rdap.arin.net/registry/entity/DIGIT19-ARIN

OrgNOCHandle: NOC32014-ARIN
OrgNOCName:   Network Operations Center
OrgNOCPhone:  +1-646-827-4366 
OrgNOCEmail:  noc@digitalocean.com
OrgNOCRef:    https://rdap.arin.net/registry/entity/NOC32014-ARIN

OrgTechHandle: NOC32014-ARIN
OrgTechName:   Network Operations Center
OrgTechPhone:  +1-646-827-4366 
OrgTechEmail:  noc@digitalocean.com
OrgTechRef:    https://rdap.arin.net/registry/entity/NOC32014-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2025, American Registry for Internet Numbers, Ltd.
#

However, caddyserver.com's IP address is in the same /64 as this mystery requester, the only path requested is the location of my package, and the requests started when I registered the package on /account/register-package, so I strongly suspect that Caddy's API is the source of these requests:

$ dig +short caddyserver.com AAAA
2604:a880:2:d0::21b0:6001

$ jq 'select(.request.remote_ip == "2604:a880:2:d0::17d:6001").request.uri' ~web/caddy/logs/access.log | sort | uniq --count
   2543 "/tools/speedtest"
  33512 "/tools/speedtest?go-get=1"

If this is isn't you, then sorry for the noise. But if this is you, then I'd recommend

1. To make it easier to figure out who is the source of these requests, using a more descriptive User-Agent than Go-http-client/2.0 and adding reverse DNS to the IP.

2. Not making 10k requests/day to the package URL. The page that the Caddy API is requesting is heavily cached and hosted by Caddy, so the extra requests aren't actually causing me any problems, but it's probably not a great idea in general to make 10k requests/day to a single URL.

In case it's any help, here's the logs for the most recent request from this IP:

{
  "level": "info",
  "ts": 1764121455.906641,
  "logger": "http.log.access.log0",
  "msg": "handled request",
  "request": {
    "remote_ip": "2604:a880:2:d0::17d:6001",
    "remote_port": "35540",
    "client_ip": "2604:a880:2:d0::17d:6001",
    "proto": "HTTP/2.0",
    "method": "GET",
    "host": "maxchernoff.ca",
    "uri": "/tools/speedtest?go-get=1",
    "headers": {
      "Accept-Encoding": [
        "gzip"
      ],
      "User-Agent": [
        "Go-http-client/2.0"
      ]
    },
    "tls": {
      "resumed": false,
      "version": 772,
      "cipher_suite": 4865,
      "proto": "h2",
      "server_name": "maxchernoff.ca"
    }
  },
  "bytes_read": 0,
  "user_id": "",
  "duration": 0.000118118,
  "size": 0,
  "status": 301,
  "resp_headers": {
    "Alt-Svc": [
      "h3=\":443\"; ma=2592000"
    ],
    "X-Content-Type-Options": [
      "nosniff"
    ],
    "Location": [
      "https://www.maxchernoff.ca/tools/speedtest?go-get=1"
    ],
    "Content-Type": [],
    "Cache-Control": [
      "max-age=3600"
    ],
    "Content-Security-Policy": [
      "default-src 'none'; frame-ancestors 'none'; form-action 'none'; style-src 'self' 'unsafe-inline'; img-src 'self' https: data:; script-src 'self'; script-src-elem 'self'; media-src 'self';"
    ],
    "Server": [
      "Caddy"
    ],
    "Strict-Transport-Security": [
      "max-age=31536000; includeSubDomains; preload"
    ],
    "Cross-Origin-Resource-Policy": [
      "same-origin"
    ]
  }
}

[mohammed90]

There are lots of layers at play here. To be clear, we do cache packages+versions. Moreover, we use standard Go tooling, which has Go Module Proxy as additional cache layer. What I see happening is the first scan for documentation probably fails on first pull, so the doc scan is postponed to be processed lazily on browse of the package. Bots are vigilant, so they keep pulling the page all the time.

All that said, the module path is not compatible with Go tooling. Go tries to pull your module using the URL of the module path with the query ?go-get=1. Your server responds with 404. I wonder if this is why the Go Module Proxy isn't caching your package.

[gucci-on-fleek]

@mohammed90

All that said, the module path is not compatible with Go tooling. Go tries to pull your module using the URL of the module path with the query ?go-get=1. Your server responds with 404. I wonder if this is why the Go Module Proxy isn't caching your package.

Ah, my bad, sorry. It was working before, but when I saw all the log entries, I added a matcher to try and filter them out, but that instead caused any ?go-get=1 requests to return a 404. I reverted that change 24 hours ago, but that doesn't seem have made any difference; since then, I've gotten 20252 requests from 2604:a880:2:d0::17d:6001.

There are lots of layers at play here. To be clear, we do cache packages+versions. Moreover, we use standard Go tooling, which has Go Module Proxy as additional cache layer. What I see happening is the first scan for documentation probably fails on first pull, so the doc scan is postponed to be processed lazily on browse of the package. Bots are vigilant, so they keep pulling the page all the time.

The latest version of the module is on pkg.go.dev, and I'm able to download https://proxy.golang.org/maxchernoff.ca/tools/speedtest/@v/v0.1.2.zip, so presumably that means that it should be available in the Go module proxy. And the module documentation on caddyserver.com looks correct, so I think that it's successfully pulling the module. But here's the summary of requests for the URL /tools/speedtest?go-get=1 that I've received since last Friday (~5 days ago):

Requests	Source
58803	2604:a880:2:d0::17d:6001
470	AS15169 (Google LLC)
1	Other

[gucci-on-fleek]

As an update, this issue is still ongoing. Between 2025-11-17 and 2026-01-18, I have received a total of 757 195 requests from 2604:a880:2:d0::17d:6001, which averages out to one request every 7.05 seconds over the past 2 months. Over this same time frame, I have received a total of 3 572 requests for /tools/speedtest?go-get=1 from all other IP addresses.

[mholt]

I will look into this when I sit down at my desk next. That's wild.