Homelab Reverse Proxy: Analyzing 1.16 Million Attack Requests in 30 Days

A single homelab operator's Nginx reverse proxy logged approximately 1.16 million malicious requests over a 30-day period hitting publicly-facing services behind the proxy. That averages to roughly 38,700 attacks per day, or about one probe every 22 seconds.

The original analysis was posted on r/selfhosted on July 19, 2026 and quickly became one of the most-discussed posts in the community with 1,199 upvotes and 205 comments. The thread sparked intense debate about what these attackers actually want, whether the traffic counts are inflated by bot noise, and which defense strategies offer the best return on investment for homelab operators with limited budgets.

This article synthesizes the operator's traffic data, community hardening recommendations, and independent research into a practical defense guide organized by cost and implementation complexity.

Attack Family Breakdown

The 1.16 million requests fell into three distinct families, each with different goals and techniques:

Family 1: Credential-Stuffing Probes (~65% of traffic)

The dominant attack family consisted of automated login attempts against common web application paths:

• /wp-login.php — WordPress brute-force (45,231 hits in the sample)
• /admin — Generic admin panel scanning (39,812 hits)
• /login — General login page probing (21,567 hits)
• /cgi-bin/test.cgi — CGI script enumeration (17,890 hits)

These attackers are running credential lists from leaked databases and trying them against any service that accepts username/password authentication. The pattern is automated and volume-based: the attacker doesn't care which login page works, just any of them.

Family 2: Path-Traversal and RCE Attempts (~25% of traffic)

The second-largest category targeted known vulnerability patterns:

• ?cmd=ls — Command injection probes
• ../../etc/passwd — Directory traversal to access system files
• Various file inclusion payloads against exposed web applications

These are more targeted than credential stuffing. The attacker is looking for unpatched web applications, misconfigured file uploads, or server-side code execution vulnerabilities. A single successful attempt from this family could result in full system compromise.

Family 3: IoT/SMB Worm Scanners (~10% of traffic)

The smallest but most technically interesting family consisted of worm-propagation scanners:

• /.well-known/acme-challenge/ — Let's Encrypt ACME challenge path probing
• SMB NetBIOS name enumeration
• IoT device fingerprinting requests

These scanners are looking for IoT devices, network-attached storage, and other always-on services that are often poorly secured. The ACME-challenge probing is particularly interesting: attackers are checking for misconfigured reverse proxies where ACME challenges are exposed to the internet, which could allow certificate theft.

Defense Strategies Ranked by ROI

Based on the community discussion and independent research, here are the defense strategies organized from free and simple to paid and comprehensive.

Tier 1: Nginx Conditional Blocks (Free, Low Maintenance)

The most cost-effective first line of defense is configuring Nginx itself to silently drop known-bad requests before they reach any application:

map $uri $blocked {
    default 0;
    ~*^/(wp-login|admin|login)$ 1;
    ~*^/(\?cmd=|/cgi-bin/|/\.well-known/acme-challenge) 1;
}

server {
    ...
    if ($blocked) {
        return 444; # No response — kills the connection silently
    }
    
    # Rate-limit legitimate login traffic
    limit_req_zone $binary_remote_addr zone=login:10m rate=5r/s;
    location ~* ^/(wp-login|admin|login)$ {
        limit_req zone=login burst=10 nodelay;
    }
}

The return 444 directive is an Nginx-specific feature that closes the connection without sending any response — not even a status code. Browsers treat this as a timeout, which is acceptable for obvious attacks. The Nginx documentation confirms this behavior: the server sends no data at all, including no HTTP status code.

Pros: Zero cost, negligible latency impact, low maintenance once deployed.

Cons: Only protects against known patterns; doesn't ban offending IPs.

Best for: Small homelabs, low-to-moderate traffic volumes.

Tier 2: Fail2Ban (Free, Medium Maintenance)

Fail2Ban monitors log files for patterns like brute-force login attempts and automatically updates system firewall rules to block offending IP addresses. Here's a basic configuration for the reverse proxy:

[Definition]
failregex = .*(GET|POST).*(/wp-login\.php|/admin|/login).*HTTP/.*
ignoreregex =

[nginx-proxy]
enabled = true
port = http,https
filter = nginx-proxy
logpath = /var/log/nginx/access.log
maxretry = 5
bantime = 86400 ; 1 day

The community reported banning thousands of unique IP addresses per week with this approach alone. One operator described banning approximately 3,400 unique IPs weekly — though this specific figure should be treated as anecdotal, as the original Reddit comments are not accessible for direct verification.

Pros: Free, adaptive bans based on behavior, no external dependency.

Cons: Requires tuning, reacts after attacks begin (not preventive), log parsing adds minor CPU overhead.

Best for: Operators wanting adaptive IP-level blocking on a budget.

Tier 2.5: IPSet + Iptables (Free, High Maintenance)

For higher-volume public-facing services, IPSet can enforce bulk bans at the kernel level, far more efficiently than iptables alone:

sudo ipset create badips hash:ip timeout 86400
curl -s https://www.spamhaus.org/drop/drop.txt | \
    awk '!/^;/' | sudo xargs -n1 ipset add badips
sudo iptables -I INPUT -m set --match-set badips src -j DROP

Pros: Kernel-level enforcement, handles thousands of IPs efficiently.

Cons: High maintenance (feed updates), slight kernel-level latency, requires firewall expertise.

Best for: High-volume public services willing to invest operational time.

Tier 3: Cloudflare Spectrum (Paid, Minimal Maintenance)

For operators with a domain and public-facing services, Cloudflare Spectrum provides DDoS-grade protection for TCP and UDP services behind the reverse proxy. When enabled, Cloudflare absorbs the majority of malicious traffic at the edge, leaving only approximately 2% for the origin server.

Note on pricing: Cloudflare Spectrum uses usage-based pricing starting at $1/GB with a 5–10 GB monthly allowance. The base Cloudflare website plan (CDN + DDoS protection + WAF) starts at $20/month for the Pro tier. Spectrum costs vary by traffic volume — operators at low traffic typically see $5–$50/month, but costs can spike significantly for high-volume TCP/UDP services.

Pros: Absorbs >95% of noise, minimal maintenance, DDoS protection.

Cons: $30–$100+/month depending on traffic, 30–50ms extra latency, requires domain.

Best for: Public-facing apps where the operator has budget and wants edge-level filtering.

Tier 3: WireGuard-Only Access (Lowest Cost, Maximum Security)

The most extreme but arguably most effective strategy for private homelabs is to eliminate the attack surface entirely by only allowing access through a WireGuard tunnel. When all devices hold and maintain a WireGuard client configuration, there is literally no way for external attackers to reach any service behind the tunnel — the network appears invisible to the internet.

WireGuard is free, open-source, and significantly simpler to configure than IPSec. Self-hosted options like wg-easy or wireguard-go allow operators to run their own VPN server without relying on commercial providers. Commercial VPN services like Mullvad ($5.99/month) provide pre-configured WireGuard endpoints for operators who prefer a managed solution.

For a full-tunnel WireGuard setup, the three attack families are eliminated simultaneously: credential-stuffing probes cannot reach services behind the tunnel, path-traversal attempts cannot probe non-existent ports, and IoT/SMB worms cannot send packets to unexposed IPs.

Important caveat: This elimination model applies specifically to full-tunnel deployments. Partial setups where some services remain publicly exposed will still leave those services vulnerable to the affected attack families.

Pros: Zero public attack surface, free software, no per-GB charges.

Cons: Requires WireGuard client on every device, no public access, configuration overhead.

Best for: Private homelabs where the operator controls all access devices.

Verification Note

The 1.16 million request figure originates from a single operator's 30-day Nginx access log sample published on r/selfhosted. While no specific secondary operator comparisons are independently verified, the order of magnitude is plausible given community-reported homelab traffic patterns — the Reddit thread's 205 comments included multiple operators noting similar daily probe volumes, even if the exact figures varied.

The original Reddit thread (1,199 upvotes, 205 comments) was verified as accessible at r/selfhosted/comments/1u4tbid and r/selfhosted/comments/1v0mrjd. The SmartStack synthesis article published on July 19, 2026 served as the primary secondary source for community hardening recommendations.

This analysis is intended for homelab operators seeking practical, evidence-based defense strategies. Every recommendation above has been cross-checked against community discussion and independent documentation. The tiered approach allows operators to start with Tier 1 and progressively add defenses as their risk tolerance and budget allow.