80端口管理工具

上周三凌晨两点，端口我盯着监控面板上那条突然翘起来的管理工具流量曲线，心里咯噔一下。端口服务器CPU飙到90%，管理工具罪魁祸首是端口80端口——那个跑着Nginx的Web服务，正被一堆来自东欧IP的管理工具请求疯狂冲刷。这不是端口我第一次跟80端口较劲了。干了七年运维，管理工具我敢说，端口80端口的管理工具管理水平，基本能反映一个团队的端口基础设施成熟度。

80端口本身没什么特别的管理工具。HTTP协议默认走这儿，端口浏览器输网址不带端口号，管理工具背后就是端口它在干活。问题在于，它太“公共”了。任何扫描器、爬虫、攻击脚本，第一个问候的就是它。我见过太多服务器，80端口开着，上面跑着三四个不知名的小服务，配置文件还是两年前某位离职同事留下的，注释写着“临时用，回头改”。回头？没有回头。

管理80端口的第一件事，不是装什么花哨工具，而是搞清楚谁在监听它。ss -tlnp | grep :80 这条命令我一天能敲十几遍。输出里经常蹦出意外：一个忘了关的Python调试服务器，一个测试用的Node进程，甚至有一次是同事用nc临时传文件忘了退出。这些“寄生”进程占着80端口，正式服务反而起不来，报错还特别含糊——“Address already in use”。新手看到这行字容易懵，老手直接上lsof -i :80，谁占的一目了然。

真正让我觉得80端口管理值得单独拎出来说的，是权限和转发这两件事。Linux下绑定1024以下端口需要root，但没人愿意让Nginx以root跑。常规做法是用root启动，然后setuid降权。可有些团队图省事，直接给应用二进制文件setcap cap_net_bind_service，这玩意儿方便是方便，一旦应用有漏洞，攻击者就能拿到绑定任意低端口的能力。我个人的偏好还是Nginx做反向代理，后端应用监听8080或者9000，80端口只留Nginx一个入口。转发规则写清楚，proxy_pass指向明确，日志分开存。这样出问题的时候，查80端口的访问日志，和后端应用的错误日志，两条线并行，定位速度快一倍。

再说个具体案例。去年帮一个电商团队做排查，他们的80端口每隔几小时就卡死几分钟。监控显示连接数瞬间冲到两万，然后归零。查了半天，发现是某个运营活动页面里嵌了一个第三方统计脚本，那个脚本的域名解析偶尔会指向他们自己的服务器——DNS轮询配置错了。结果就是，用户浏览器疯狂向80端口发请求，Nginx的worker_connections设的1024，直接打满。解决方案不复杂，限流加DNS修正，但暴露的问题是：80端口的管理不能只看服务器本身，上游的DNS、CDN、甚至前端代码里的硬编码URL，都可能把流量引过来。

工具方面，netstat和ss是基础，iftop看实时流量，ngrep抓HTTP明文请求特别顺手。但工具再多，不如一条铁律：80端口上只跑一个明确的服务，配置文件纳入版本控制，每次变更走审核。我见过用Ansible批量管理80端口配置的团队，也见过手写iptables规则把自己锁在外面的倒霉蛋。差别不在工具，在纪律。

最后说个反直觉的观察。很多人以为80端口管理就是防攻击，其实更大的麻烦来自内部。开发环境、测试环境、生产环境，三个环境的80端口配置不一致，上线时才发现少了条rewrite规则。这种问题不致命，但恶心人。我的做法是，用Docker把Nginx配置打包成镜像，三个环境用同一个镜像，配置通过环境变量注入。80端口在前面挡着，后面怎么折腾都行，但前面这层，必须稳。