隐藏源站IP是现代Web安全里非常基础却极易被忽视的一环。许多业务把大量预算花在应用防火墙和代码审计上，却任由真实服务器地址暴露在公网，结果攻击者无需突破层层防护，直接对着源站IP灌流量就能让服务瘫痪。本文从实际攻防视角出发，梳理源站暴露的常见路径，并给出可操作的隐藏方案。
源站IP为什么会被暴露
要隐藏源站IP，首先得弄清楚它是怎么漏出去的。最常见的泄漏点是DNS配置不当。很多管理员在接入CDN之前，直接将根域名或子域名解析到源站IP，后续虽然加了CDN，却忘了清理历史解析记录。攻击者在安全社区或历史DNS数据库中很容易查到这些旧记录，从而拿到真实地址。另外，部分业务会使用邮件服务，而邮件头里往往包含发送服务器的IP，如果邮件系统和源站部署在同一台机器，也会间接暴露。
另一个容易被忽略的渠道是错误配置的反向代理和后端接口。有些开发人员在调试时，把后端API的地址硬编码在前端代码或配置文件中，并且这个地址直接指向源站公网IP而非内网域名。当应用打包发布后，任何人都能通过抓包或阅读静态资源找到该IP。此外，SSL证书申请日志、第三方监控探针以及GitHub泄露的配置文件，都是溯源源站的重要来源。理解这些路径，才能有针对性地做收敛。
从攻击链条看，暴露源站IP等于去掉了CDN和高防的护盾。正常情况下，流量应先经过边缘节点清洗再转发给源站；一旦IP直连，所有防护都形同虚设。因此，隐藏源站不是可选项，而是前置条件。下面我们讨论具体怎么藏。
使用反向代理与高防IP切断直连
反向代理是隐藏源站最经典的手段。通过在源站前面部署Nginx或云厂商的负载均衡，所有外部请求都先到达代理层，再由代理以内网方式访问源站。此时源站只需监听内网端口，公网防火墙禁止入站流量，从网络层就掐断了直连可能。配置上，可以在Nginx中限制只允许特定代理IP转发，并开启allow与deny规则。
# 只允许CDN回源IP段访问源站
server {
listen 80;
server_name example.ipipp.com;
allow 192.168.0.0/24;
deny all;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
}
}
高防IP则更适合对抗大流量DDoS。它的原理是提供一个拥有超大带宽的清洗中心IP，将域名解析到高防IP，攻击流量在这里被过滤，干净流量再通过专线回源到你的真实服务器。和单纯反向代理相比，高防IP解决了带宽被堵死的问题。不过高防IP通常按防护峰值收费，小型业务可以先用免费CDN隐藏，再视威胁升级。
实践中，建议把域名收敛到单一入口。不要为测试环境、后台管理单独解析公网域名到源站，这些边缘站点常成为突破口。统一走同一套代理或高防，并定期检查nginx配置中是否有遗漏的server_name直通块，才能确保没有后门。
收敛暴露面与持续性检测
技术方案部署完不代表高枕无忧，源站IP可能因为一次误操作再次暴露。因此需要建立持续性检测机制。可以写脚本周期性用第三方DNS历史接口和证书透明日志查询业务相关域名，确认没有新解析指向源站。同时，在邮件服务器与源站分离的前提下，对发出邮件头做脱敏，避免Received字段带内网或公网真实IP。
# 简单检查域名是否解析到源站IP的脚本
#!/bin/bash
SOURCE_IP="192.168.0.1"
for domain in api.ipipp.com www.ipipp.com; do
resolved=$(dig +short $domain)
if [ "$resolved" = "$SOURCE_IP" ]; then
echo "警告: $domain 直连源站"
fi
done
除了自动检测，团队还应把隐藏源站写进上线 checklist。任何新服务公网暴露前，必须确认它经过代理或高防，且源站安全组拒绝0.0.0.0/0入站。不少公司吃过亏：临时开个端口排查问题，事后忘记关，结果被扫描工具捕获。通过基础设施即代码管理网络规则，能减少人为疏漏。
最后要提醒，隐藏源站IP是纵深防御的一环，不能替代应用安全。但如果连这层都做不好，再强的WAF也守不住背后裸奔的服务器。把上文的代理配置、高防接入和周期检测组合起来，你的源站才算真正隐身于公网洪流之中。