Apache Log Analyzer: Find Attacks in access.log

Drop in an Apache or nginx access log and see who is attacking you: SQL injection, path traversal, Log4Shell and code injection attempts, .env and .git probes, scanners, wp-login.php brute force, broken links, bots and AI crawlers. Then copy a ready-made block for the worst offenders. Your log never leaves your browser: it is read and analyzed on your device, nothing is uploaded.

Drop access.log (or .log.gz) here, or click to choose a file

…or paste log lines (common, combined or vhost_combined format)

Find your log: /var/log/apache2/access.log (Debian/Ubuntu), /var/log/httpd/access_log (RHEL/Alma), ~/logs/ or cPanel → Raw Access on shared hosting. Turn findings into rules with the IP blocker and the .htaccess generator.

Your access log is the only honest witness on the server. Analytics scripts see humans who run JavaScript. The log sees everything: the bots, the scanners probing /.env at 4am, the one IP that pulled 40,000 pages yesterday. This analyzer reads it for you, right in your browser. Your log never leaves your machine.

How to use it

Drop an access_log on the page, paste lines, or click Load sample to see it work. Common and Combined formats are detected automatically, plain or .gz. Big files stream through in chunks with a progress bar, so a few hundred MB is fine.

You get:

Overview: requests, unique IPs, bandwidth, the time span, and hits over time.
Status codes: 2xx/3xx/4xx/5xx, with the top 404s and every 5xx, because those are your broken links and your crashes.
Top IPs, URLs, referrers and user agents, each clickable to filter everything else.
Bots: search engines, AI crawlers, SEO tools and generic scrapers, split from humans.
Attacks: path traversal, SQL injection, shell probes, .git/.env hunting, WordPress login and xmlrpc.php brute force, scanner User-Agents. Grouped by IP so you see the campaign, not just the noise.

Reading the attack tab

Most of what you'll see is automated and harmless if you're patched: dumb scanners hitting paths that don't exist on your box. What deserves a second look is anything that got a 200 back. A 200 on /.env or /.git/config means your secrets are public right now. Stop reading and fix that.

Then turn the worst offenders into rules. The .htaccess generator blocks dotfiles and backups, the AI bot blocker handles crawlers, and the country IP blocker walls off your login.

The log format I'd run

Combined format plus response time (%D, microseconds) and the real host. Slow URLs show up instantly:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %{Host}i" combinedplus
CustomLog logs/access_log combinedplus

Behind a proxy or CDN, %h is the proxy. Enable mod_remoteip with your proxy's ranges as trusted, and Apache logs the real client address in %a.

Old-school one-liners

For when you're on the box and want the answer in two seconds:

# top 10 IPs
awk '{print $1}' access_log | sort | uniq -c | sort -rn | head
# top 404s
awk '$9==404 {print $7}' access_log | sort | uniq -c | sort -rn | head
# who's hunting for secrets
grep -E '\.(env|git)/?' access_log | awk '{print $1, $7, $9}' | sort -u

FAQ

Is my log uploaded anywhere?

No. Parsing happens in JavaScript on your machine. Nothing is sent to AskApache. Close the tab and it's gone.

Does it handle nginx logs?

Yes, nginx's default combined format is identical to Apache's. Custom formats with extra fields at the end are fine too; unknown trailing fields are ignored.

Why are some requests marked as attacks when they look normal?

The patterns are tuned to stay quiet on ordinary URLs, but a weird slug can still trip one. Click the row to see the matching rule and judge for yourself.