为什么要关心日志里的 IP
很多站长第一次看 Web 日志,只会盯着状态码和访问量:今天 404 多不多、有没有 500、峰值流量是不是突然上来了。其实在这些数字背后,IP 才是把问题串起来的关键线索。它能告诉你请求来自哪里、是否集中在某个来源、有没有同一批地址反复尝试登录、爬虫是不是压垮了动态页面,也能帮助你判断一次异常到底是用户访问波动,还是更接近扫描、刷接口或攻击。

但 IP 分析最容易走偏:看到陌生国家就拉黑,看到访问量大就怀疑攻击,看到同一个 IP 请求很多就直接封禁。现实里的网络环境复杂得多,同一个出口 IP 后面可能是企业办公室、学校、运营商 NAT,也可能是搜索引擎、CDN 回源节点或监控系统。正确做法不是把 IP 当成单点结论,而是把它和时间、路径、状态码、User-Agent、请求频率放在一起看。
先把日志字段看完整
常见的 Nginx 或 Apache 访问日志至少会记录来源 IP、访问时间、请求方法、URL、HTTP 状态码、响应体大小、Referer 和 User-Agent。如果站点前面还有 CDN、WAF 或反向代理,还要确认日志里记录的是用户真实 IP,还是代理节点 IP。否则你看到的“高频 IP”可能只是 CDN 节点,封错以后反而会影响正常访问。
排查时可以先按时间窗口切片,例如只看异常发生前后 10 到 30 分钟,再统计访问最多的 IP、访问最多的路径、异常状态码最多的组合。比起全量日志里漫无目的搜索,这种切片更容易发现规律:某批 IP 是否集中打登录接口,某个路径是否突然被大量请求,某个 User-Agent 是否反复命中不存在的文件。
哪些 IP 行为更值得优先关注
第一类是短时间内请求频率异常高的 IP,尤其是集中访问登录页、搜索页、接口地址或动态生成页面的请求。它们未必一定是攻击,也可能是失控爬虫或错误配置的监控程序,但这类流量最容易让数据库、PHP-FPM、Node 服务或后端 API 先被拖慢。
第二类是状态码异常集中的 IP。例如大量 404 可能表示在扫描后台路径、配置文件、备份压缩包或常见漏洞入口;大量 401、403 可能表示在尝试越权或撞库;大量 499、502、504 则可能说明客户端提前断开、后端响应过慢,或者代理层与源站之间存在性能瓶颈。
第三类是访问路径高度重复却没有正常浏览链路的 IP。正常用户通常会访问首页、栏目页、文章页、静态资源,行为有一定连续性;异常请求则可能只打固定接口、只访问 wp-login.php、只扫 /admin、/.env、/backup.zip 这类路径。把路径序列拉出来看,往往比单纯看访问量更准确。
不要把地理位置当成唯一依据
很多 IP 查询工具会显示国家、城市、运营商和 ASN,这些信息有参考价值,但不能直接等同于安全结论。云服务器、代理出口、移动网络 NAT、企业专线、海外办公人员,都可能让地理位置看起来“不合理”。如果业务本来面向全球用户,粗暴按地区封禁会带来误伤;如果业务只服务国内客户,也要先观察是否有正常客户、搜索引擎或第三方服务从境外访问。
更稳妥的做法是分层处理:对明显扫描路径和暴力破解行为做规则拦截;对高频但不确定的来源先限速或挑战验证;对已确认无业务价值的区域再做更严格策略。服务器侧可以在 Nginx、iptables、firewalld 或应用层限流里处理,前面有 CDN/WAF 时则优先在边缘层拦截,减少源站压力。
从一条命令开始做粗排查
在 Linux 服务器上,最简单的入口是先统计访问量最高的来源 IP。以 Nginx 默认访问日志为例,可以使用 awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head 查看 Top IP。再进一步,可以把 IP 和状态码组合起来统计,例如提取第 1 列和第 9 列,观察哪些来源制造了大量 404、403 或 5xx。
如果日志量很大,不建议直接在生产高峰期对超大文件反复 sort。可以先按时间切割日志,或使用 goaccess、lnav、ELK、Loki、ClickHouse 等工具做查询。对中小站点来说,先把最近半小时日志复制一份再分析,通常已经足够定位多数突发问题。
如果站点托管在云服务器上,也要结合安全组、防火墙、负载均衡、CDN 日志一起看。单看 Web 访问日志只能看到已经到达应用层的请求,看不到连接层丢包、端口扫描、SYN 洪泛或上游线路波动。需要稳定承载网站业务时,可以结合 速维云服务器 的带宽、线路和防护能力做基础评估,再决定是在源站优化、边缘限流,还是调整架构。
误封比漏看更麻烦
处理异常 IP 时,最忌讳“一看不顺眼就永久封禁”。误封搜索引擎会影响收录,误封 CDN 回源会导致全站异常,误封企业出口会让一整家公司访问不了网站。更合理的策略是先短期封禁或限速,例如 10 分钟、1 小时、24 小时,并记录触发原因,后续根据日志复盘是否需要长期规则。
规则也要尽量具体。能按路径限速,就不要全站封;能按行为组合拦截,就不要只按 IP 段拦;能在 WAF 挑战验证,就不要直接丢弃所有请求。对登录、注册、搜索、评论、上传、接口等高风险入口,可以单独设置更严格的频率限制和验证码策略,避免影响普通页面访问。
把 IP 分析变成日常机制
一次排查解决的是眼前问题,长期稳定靠的是机制。建议至少保留足够周期的访问日志和错误日志,建立基础指标:总请求量、4xx/5xx 比例、Top IP、Top URL、登录失败次数、搜索接口调用次数、后端响应时间。只要这些指标有基线,异常出现时就能更快判断是不是流量结构变了。
对于小团队来说,不一定一开始就上复杂平台。先把日志轮转配置正确,避免磁盘被打满;再定期抽样查看 Top IP 和异常路径;最后把高风险行为接入告警。等业务访问量上来后,再逐步接入集中日志和可视化面板。IP 分析的目标不是“抓坏人”,而是尽快判断异常来源、影响范围和处理优先级,让网站在压力下仍然可控。














