清理废弃http监听规则需先识别真实流量、外部依赖及非业务功能，再分场景安全移除，最后用https原生能力重构，并通过删前测试与删后日志验证闭环。
清理和重构废弃的 HTTP 监听规则，本质是安全收敛与配置瘦身——不是简单删掉 listen 80，而是确认它是否还承担真实业务、是否被重定向逻辑依赖、是否残留未迁移的健康检查或监控探针。盲目删除可能造成监控告警失灵、爬虫抓取中断，甚至内部服务调用失败。
先识别：哪些 HTTP 监听真该下线？
别只看配置文件里有没有 listen 80。重点查三类实际行为：
-
是否还有主动流量进入：用
nginx -T | grep -A5 "listen 80"定位 server 块，再结合 access 日志（如awk '$9==200 && $7~/^\/api\// {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -5）确认是否有非重定向请求 -
是否被其他系统依赖：检查运维平台、健康检查 URL（如 Consul、Zabbix）、CI/CD 部署脚本中是否硬编码了
http://地址；某些旧版 SDK 或内网工具仍直连 HTTP 端口 -
是否承担非业务功能：比如 Prometheus 的
/metrics、Let’s Encrypt 的/.well-known/acme-challenge、或自定义的/healthz探针——这些可保留，但应独立 server 块并限制访问来源
再清理：分场景安全移除
不是“一刀切”，而是按用途分类处理：
-
纯重定向型 HTTP server：仅含
return 301 https://$host$request_uri;的块，且无 location 配置其他路径，可直接删除整个 server 块 -
混合型 HTTP server：既有重定向，又开放了
/healthz或/metrics，建议拆分——把探针路径迁移到专用监听（如listen 8080），再删除原 80 端口 server -
遗留调试端口：如
listen 8080或listen 8888，用于开发临时访问，应在配置中标注# DEV-ONLY: remove before prod deploy并统一禁用
后重构：用 HTTPS 原生能力替代 HTTP 逻辑
很多旧 HTTP 规则其实是为绕过 HTTPS 限制而设，现在可回归标准做法：
-
HTTP 跳转不再靠 Nginx return：改用 HSTS（
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;），让浏览器自动升级后续请求 - Let’s Encrypt 验证不走 80 端口：改用 TLS-ALPN-01 挑战（需 Certbot ≥1.12），全程走 443，彻底消除对 HTTP 端口的依赖
-
内部服务通信启用 HTTPS 回环：若后端服务支持 TLS，把
proxy_pass http://backend升级为proxy_pass https://backend，配合proxy_ssl_verify off（内网可信时）和证书路径配置
验证闭环：删前测影响，删后验结果
每删一个 HTTP server，必须做两件事：
-
删前模拟测试：用
curl -I http://your.site/healthz和curl -I http://your.site/确认当前响应是否符合预期（301 还是 200） -
删后日志追踪：上线后 24 小时内，监控
grep "HTTP/1.0" /var/log/nginx/access.log | wc -l和grep "80 " /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr，排查残留 HTTP 流量来源
