300000 Requests Hit Her Server in One Morning Her Website Never Felt a Thing

The Morning Everything Stopped

A developer runs a small operation on her own infrastructure. Not a Fortune 500 setup. Not a cloud-managed enterprise environment with a dedicated ops team watching dashboards around the clock. A real server, a real GitLab instance, a real business that depends on that infrastructure being available when her team needs it.

One morning she opened her laptop and found her GitLab environment down. Not slow. Not degraded. Down. The logs told the story in numbers: 299,991 requests from a single user agent string, meta-externalagent/1.1, arriving in a concentrated window that her server had no mechanism to absorb. The requests were not a criminal attack in the traditional sense. They were Meta's web crawler, documented in Meta's own developer documentation, doing what crawlers do, at a volume and a rate that a small server running real work had no chance of handling without some kind of protection sitting in front of it.

299,991 requests. One morning. One user agent string. The server had no rule for it, so it processed every single one. Only 5 should have passed.

Her first question was whether she had legal recourse. That is a reasonable question and a lawyer is better placed to answer it than an engineer. The engineering question is different. The engineering question is why the server was exposed to that volume of requests in the first place, and what a fifteen-minute configuration change would have done to that morning.

The answer to the engineering question is simple. A reverse proxy reading that user agent header, applying a rate limit of five requests per second, would have let five through and dropped 299,986 before they ever touched the server. Her GitLab environment would have processed a normal load. Her team would have had a normal morning. The 299,986 blocked requests would have returned a 429 status and Meta's crawler would have moved on.

The server never needed to know the wave existed.

What a Reverse Proxy Actually Does in Plain Language

Most business owners who run any kind of web presence have heard the term reverse proxy without fully understanding what it means in practical terms. The concept is not complicated. It is a guard at the outer gate of your infrastructure whose job is to read every incoming request before it reaches your actual server and decide, based on rules you set, which requests get through and which do not.

[ 299,991 Meta Crawler Requests — Massive Wave ]
   |   |   |   |   |   |   |   |   |   |   |
   v   v   v   v   v   v   v   v   v   v   v

+-----------------------------------------------+
|  REVERSE PROXY — The Guard at the Outer Gate  |
|  Reads header: "meta-externalagent/1.1"        |
|  Rule: Max 5 requests per second               |
|  ACTION: Drops / blocks everything above       |
+-----------------------------------------------+

        |  ( Only 5 requests pass through )  |
                          v

+-----------------------------------------------+
|  YOUR ACTUAL SERVER — The Core Building       |
|  Processes a tiny, normal load                |
|  Stays online perfectly — 0% CPU stress       |
+-----------------------------------------------+

In this case the rule would have been straightforward. If the incoming request carries the header meta-externalagent/1.1, allow a maximum of five per second and drop everything above that threshold instantly. The drop happens at the proxy layer, in milliseconds, before the request consumes any meaningful resource on the server behind it. The server never sees the flood. It processes the trickle that the proxy allowed through and continues running normally.

The same mechanism works for any traffic pattern that does not match legitimate human behaviour. A sudden spike from a single IP address. A scraping bot cycling through thousands of pages in minutes. A distributed pattern that looks like a coordinated attempt to exhaust server resources. The reverse proxy reads the pattern, applies the rule, and either blocks, rate-limits, or challenges the request before it reaches the infrastructure that is doing real work.

For a business owner the practical meaning is this. Your website, your application, your booking system, your client portal: all of these run on a server that has finite capacity. Every request that server processes takes a small slice of that capacity. When requests arrive faster than the server can process them, performance degrades and eventually the server stops responding entirely. The reverse proxy ensures that the requests your server processes are the ones from real people with real intent, and that everything else is handled at the edge before it becomes your server's problem.

Why This Is Not Just a Technical Problem

A developer's GitLab going down is inconvenient and potentially expensive in lost development hours. For a business running its customer-facing website on similar infrastructure without a proxy layer, the same event has a different cost profile.

A service business spending $3,000 a month on Google Ads is paying for visitors to arrive at its website continuously throughout the day. If a crawler event, a bot spike, or an unmanaged traffic surge takes the site down during business hours, every paid visitor who arrives during that window sees an error page. The ad spend continues. The clicks continue. The server returns nothing. The Technical Tax in that scenario runs not at the slow drip of a six-second load time but at the full cost of every click that landed during the outage.

The businesses most exposed to this are the ones that moved their infrastructure to a managed hosting plan, accepted the default configuration, and never added a proxy layer because nobody told them to and the host never flagged it as missing. The managed host keeps the server running. It does not configure intelligent traffic filtering on your behalf. That is a different service and it is almost never included in a standard hosting plan.

The reverse proxy is also the layer where the speed improvements that matter most to ad performance live. A proxy that caches static assets, compresses responses, and terminates SSL at the edge rather than at the origin server is doing three things simultaneously that reduce load time for real visitors. The same infrastructure that protects against a crawler flood is the infrastructure that makes a paid visitor's first experience of the site faster, which is the factor that most directly determines whether that visitor becomes a lead.

The Auditor's Take

The technical setup that would have prevented the outage is not exotic. Nginx with a rate limiting directive on the meta-externalagent user agent string is a configuration that takes minutes to write and seconds to deploy. Cloudflare's free tier includes bot management that would have caught this pattern automatically without any custom configuration at all. The protection exists. It is accessible. It is in many cases free or close to it.

# nginx.conf — Rate limit Meta crawler
# Step 1: Define rate limit zone in http block

limit_req_zone $http_user_agent zone=crawler_limit:10m rate=5r/s;

# Step 2: Apply in your server block

server {
  location / {
    if ($http_user_agent ~* "meta-externalagent") {
      limit_req zone=crawler_limit burst=5 nodelay;
    }
  }
}

# Requests above 5/sec return 429 Too Many Requests
# Your origin server never sees the excess load

The gap is not technical availability. The gap is awareness. The businesses and developers running public-facing infrastructure without a proxy layer are not making an informed decision to skip it. They are running a default configuration that nobody has ever examined against the actual traffic patterns hitting their server.

The specific user agent string involved — meta-externalagent/1.1 — is documented by Meta in their own developer documentation. It is not hidden. It is not a zero-day exploit. The configuration to handle it takes fifteen minutes. The morning that went wrong was a gap between publicly available information and infrastructure that had never been audited against it.

Every web server exposed to the public internet is receiving traffic from automated systems right now. Crawlers, scrapers, vulnerability scanners, uptime monitors, and AI training pipelines are all making requests to public servers continuously. The question is not whether your server receives this traffic. It does. The question is whether anything is reading those requests before they reach your server and deciding which ones deserve a response.

For most small business servers, the answer is nothing. The request arrives, the server processes it, and the capacity that was consumed by a bot is capacity that was not available to the paying customer who clicked your ad one second later.

The guard at the outer gate is not a luxury. It is the layer that determines whether your server's capacity is spent on real people or on traffic that was never going to become a customer.

The server is back up. The configuration that would have prevented the outage takes about as long to implement as it took to read this article. The decision to implement it or not is an infrastructure decision with a direct line to business continuity and ad spend efficiency.

The wave does not stop arriving. The question is whether anything is reading it before it hits the building.

Based on a real event reported publicly in May 2026. Technical details drawn from Meta's published developer documentation and standard nginx configuration practice. The diagnosis is always free.