A Fake Googlebot Hit My Laravel Server 3,300 Times: How I Investigated It with Nginx Logs

On September 16, 2026, I noticed an unusual signal in ICanUp analytics: raw views spiked sharply while deduplicated views did not follow the same curve.

At first glance, it could have looked like sudden traffic growth. In practice, such a large gap between the two metrics is a useful signal of repeated automated traffic.

Nginx access logs led me to a specific source. One IP generated about 3,300 HTTP requests in a day, identified itself as Googlebot, and systematically probed .env, credentials, cloud keys, WordPress configs, and other potentially sensitive files.

Other bot dominated the bot breakdown, while deduplicated views remained far below the raw count.

The geography breakdown also shifted heavily toward one country. That alone did not prove anything, but it strengthened the signal that the traffic pattern was unusual.

These numbers are not expected to match the Nginx request count. The access log sees every HTTP request, including probes for nonexistent paths and redirects, while application analytics counts only views that satisfy its own tracking contract.

My first step was to inspect which IP addresses and User-Agent strings were repeating in the Nginx access log for that day.

The log repeatedly showed 94.154.46.243 with a User-Agent claiming to be Googlebot.

A User-Agent by itself proves nothing. It is just a request header that any HTTP client can set.

One IP generated about 3,300 requests during the day. Some requests arrived in very dense bursts, which looked much more like automated path probing than normal search crawling.

This result was critical. A 301 does not mean the scanner downloaded the requested file.

The requests reached the HTTP endpoint and Nginx redirected them to HTTPS. The next step was therefore to inspect the redirect configuration and verify the HTTPS behavior directly.

The configuration confirmed separate HTTP server blocks, HTTP to HTTPS redirects, and HTTPS virtual hosts for both production and development.

In the available logs, I continued to see the same HTTP requests returning 301, including probes for /.env.stripe, /.env.paypal, /.env.aws, /.env.redis, and /credentials.txt.

I found no 200 OK responses for those sensitive paths in the traffic I investigated.

Public servers are scanned constantly. A request for /.env is not, by itself, evidence of compromise.

The more important question is: what did the server actually return?

My investigation did not stop at "someone requested .env". I checked response codes, redirects, HTTPS behavior, Nginx rules, and specific sensitive paths.

• Compare raw and deduplicated views if your analytics already shows an anomaly.
• Find the most active source IPs in the Nginx access log.
• Inspect User-Agent strings, but never treat them as proof of identity.
• Inspect the exact requested paths for a suspicious IP.
• Count HTTP response status codes.
• Verify redirect behavior and HTTPS server blocks.
• Search all available Nginx access logs.
• Test sensitive files directly over HTTPS.
• Look for 200 responses on sensitive paths instead of judging the incident only by request volume.
• Verify that dotfiles, Git metadata, and configuration files are not publicly accessible.

The analytics chart was what sent me to the Nginx logs in the first place.

Raw views jumped sharply while deduplicated views remained much lower. That is a useful signal for a large amount of repetitive automated traffic.

For a technical site, I find it useful to see humans, known crawlers, AI crawlers, unknown bots, raw views, and deduplicated views separately instead of relying on one total number.

During the review, I also noticed that the server exposes the exact Nginx version in response headers:

server: nginx/*.*.* (Ubuntu)

This was not the cause of the scanning and it is not evidence of a vulnerability. Still, there is usually no need to advertise the exact version.

• I do not describe this incident as a successful breach.
• I do not treat a Googlebot User-Agent as proof that the request came from Google.
• I do not treat a 301 response as proof that a file was exposed.
• I do not infer a data leak merely from thousands of requests for .env.
• I do not present server_tokens off as the security fix for scanner traffic.
• I do not block an entire country because of one suspicious source IP.
• I do not rely on one analytics metric without checking server logs.

On September 16, the sharp gap between raw and deduplicated views in ICanUp became the first signal of a large burst of automated scanning traffic.

Nginx logs showed a client claiming to be Googlebot, generating about 3,300 requests during the day and probing paths for .env, credentials, cloud keys, and configuration files.

The requests themselves were not proof of compromise. Most responses were 301 on HTTP, while the critical HTTPS paths I checked returned 403 or 404. I found no evidence in the investigated traffic that sensitive files were successfully retrieved.

My main lesson is simple: when bot traffic looks suspicious, move from the chart to the logs, from User-Agent to behavior, and from the requested path to the actual HTTP response.