LeakIX Is Scanning Your Server Right Now — Here’s What It’s Looking For and How Nginx 444 Shuts It Down

Last week’s traffic logs for two sites we manage — imagewize.com and aseonomics.com — both showed the same user agent hammering dozens of endpoints: Mozilla/5.0 (l9scan/2.0.434313e2030323e2534323e2838313; +https://leakix.net). Eighty-two requests on each site, plus two requests using an HTTP method literally named LEAKIX. Probes for known exploit paths returned 444; probes for paths that simply don’t exist returned 404. Either way, LeakIX found nothing. Here’s what it is, what it was looking for, and why we deliberately leave it unblocked.

What Is LeakIX?

LeakIX (leakix.net) is a security search engine — think Shodan, but focused specifically on finding exposed or leaking services. It crawls the public internet around the clock, cataloguing servers that have accidentally exposed configuration files, API documentation, admin interfaces, debug endpoints, or internal tooling. Security researchers and red teams use it to find real vulnerabilities before malicious actors do.

The project is legitimate and even somewhat respected in the security community. It operates from known IP ranges and identifies itself openly in its user agent string. The problem is that its scan pattern is indistinguishable from what a malicious actor would do during reconnaissance — because that’s exactly what reconnaissance looks like.

What It Was Probing For

Looking at the 404 section of the aseonomics.com traffic report, the endpoints LeakIX requested tell a clear story about what it expected to find on an average server:

Endpoint Probed	What It’s Looking For
/swagger-ui.html, /swagger/index.html, /v2/api-docs, /v3/api-docs	Exposed REST API documentation (Swagger / OpenAPI) — reveals every available endpoint and parameter
/webjars/swagger-ui/index.html	Spring Boot / Java apps that bundle Swagger UI as a webjar dependency
/v2/_catalog	Docker Registry API — if exposed, lists every Docker image stored on the server
/telescope/requests	Laravel Telescope debug dashboard — shows every request, query, and exception on the app in real time
/trace.axd	ASP.NET application trace handler — logs every request with full headers and session data
/server-status	Apache mod_status — exposes active connections, request rates, and worker states
/config.json	Misconfigured apps that accidentally serve their config file publicly
/.well-known/security.txt	Legitimate — checking for a responsible disclosure policy (RFC 9116)
/s/[hash]/_/;/META-INF/maven/...	Jira path traversal probe — attempts to read internal Maven POM files via a known Jira vulnerability

None of these are WordPress-specific. LeakIX doesn’t know what’s running on a server before it starts scanning — it runs the same playbook against every IP it encounters. Our sites run WordPress on Trellis/Bedrock, so none of these paths exist. Every single request hit a dead end.

The LEAKIX HTTP Method

Two of the requests used an HTTP method literally named LEAKIX — not GET, POST, or any standard method. This is a fingerprinting technique. A misconfigured or permissive server might respond to unknown HTTP methods rather than rejecting them, which itself reveals information about the server software and configuration. A hardened server returns nothing.

Both sites logged these as 444 — Nginx closed the connection before sending a single byte in response.

What Nginx 444 Does — and Why It’s Better Than 403

HTTP status 444 is not part of the official HTTP specification. It’s an Nginx-specific status code that means: close the connection immediately and send nothing. No headers, no body, no status line — just a TCP RST or FIN. The client receives silence.

Compare that to a standard 403 Forbidden response:

	403 Forbidden	444 No Response
Server sends headers	Yes	No
Server sends body	Yes	No
Reveals server software	Often (via Server header)	Never
Bandwidth used	Yes — even small	Zero
Scanner learns the path exists	Yes — it got a real response	No — ambiguous to the scanner
Retry likelihood	Higher — the server responded	Lower — looks like a network drop

A 403 tells the scanner “I understood your request and I’m denying it.” A 444 tells it nothing. From the scanner’s perspective, the request may have been dropped by a firewall, the server may have crashed, or the TCP stack may have timed out. This ambiguity is the point.

How We Have It Configured

The Trellis stack has three layers that produce 444 responses, none of which require knowing anything about LeakIX in advance:

Layer 1 — IP deny list. Confirmed bad actors (brute-force IPs, webshell scanners, SQL injection sources) are explicitly listed in nginx-includes/all/deny-ips.conf.j2. When a denied IP connects, Nginx drops the connection before the request reaches WordPress or PHP-FPM. These entries are added manually after reviewing AbuseIPDB scores and access log patterns.

# nginx-includes/all/deny-ips.conf.j2
# 2026-05-25: wp-login.php brute force, 192–474 attempts, AbuseIPDB 100/100
deny 192.176.172.166;
deny 123.30.233.13;
# ... 69 entries total

Layer 2 — Path-level exploit rules. A separate seo-redirects.conf.j2 include blocks known attack filenames with return 444, regardless of which IP or user agent is asking. This is where LeakIX’s probes for PHP shells and exploit paths hit the wall:

# nginx-includes/imagewize.com/seo-redirects.conf.j2
# Block PHP file scanner probes in document root
location ~ ^(?!/wp/wp-admin/).*/(admin|info|phpinfo|shell|c99|r57|alfa|wso)\.php$ {
    return 444;
}

Layer 3 — Default server catch-all. Trellis ships with a no-default.conf.j2 that returns 444 for any request that doesn’t match a configured virtual host. Probes sent to the bare IP address, or with an unrecognized Host header, hit this before reaching any site config:

# roles/wordpress-setup/templates/no-default.conf.j2
server {
  listen 80 default_server deferred;
  return 444;  # Drop requests for unknown hosts
}

Together, these layers mean that LeakIX’s probes for known exploit paths return 444 (path rules), probes sent to the wrong host return 444 (default catch-all), and probes for paths that simply don’t exist on a WordPress install return 404. None of it touches PHP-FPM. None of it required us to do anything specific about LeakIX.

Should You Block LeakIX Specifically?

We deliberately do not block LeakIX on our sites. It self-identifies, operates in the open, and it is one of the few automated scanners whose findings are worth paying attention to. If LeakIX ever found something on our server — an exposed staging environment, a debug endpoint left open, a misconfigured API — that would be genuinely useful signal. The cost of letting it scan is a few dozen log lines per week. The benefit is an independent check on whether something is inadvertently exposed.

The 444 responses it received on both sites were not from an explicit LeakIX block. They came from Nginx path-level rules that reject known exploit patterns regardless of who is asking — the Jira path traversal probe, the non-standard LEAKIX HTTP method, and a handful of well-known attack paths all hit rules that were already in place for malicious scanners. LeakIX happened to probe the same paths. The benign probes — Swagger UI, Docker registry, Laravel Telescope — returned 404 because those services simply don’t exist on a WordPress stack.

The right call is to block bad-faith scanners and brute-force IPs aggressively, while leaving legitimate security research tools unblocked. If LeakIX shows up in your logs and everything returns 404 or 444, you’re in good shape. If it returns a 200 on something you didn’t expect — investigate that before reaching for the IP deny list.

The Broader Picture

LeakIX is the well-behaved version of this scan pattern. The same endpoints get probed by thousands of less-transparent tools daily. Over the same 7-day window that LeakIX generated 82 requests on aseonomics.com, the site logged 83 Nginx 444 responses total — meaning nearly all of the hard-blocked traffic was scanner activity. On imagewize.com, 3,326 requests returned 403 and 29 returned 444 over the same period, with the bulk of that being brute force attempts against wp-login.php.

The takeaway is not that these sites are under unusual attack. This is what any public-facing server looks like. The question is whether your infrastructure handles it gracefully — dropping bad traffic before it consumes resources — or whether every probe gets handed off to PHP and processed as a real request.

On a properly configured Trellis stack, the answer is the former. LeakIX scanned both sites — known exploit paths returned 444, non-existent WordPress paths returned 404, found nothing useful, and moved on. Total impact: zero.

Frequently Asked Questions

• Is LeakIX illegal or malicious? No. LeakIX is a legitimate security research platform that openly identifies itself. Its scans are automated but not targeted — it probes the same endpoints on every server it encounters. Some operators allow it, others block it.
• Does Nginx 444 prevent the scanner from retrying? It doesn’t guarantee it, but automated scanners that receive no TCP response typically move on faster than those that receive a 403. Many scanners interpret a silent drop as a network-level block and deprioritize that IP.
• Will blocking LeakIX cause any SEO issues? No. LeakIX is not a search engine crawler and does not affect indexing. Blocking it has no SEO impact.
• What if LeakIX actually finds something on my server? If it finds an exposed endpoint, that’s valuable signal — it means you have a real misconfiguration. Fix the underlying issue rather than just blocking the scanner. The scanner identified a problem that malicious actors could find through the same methods.
• How do I add an IP to the Nginx deny list on a Trellis setup? Add deny IP_ADDRESS; to your nginx-includes/all/deny-ips.conf.j2 file and run trellis provision --tags wordpress-setup production from your Trellis directory. Nginx reloads automatically after provisioning.