把网站接入反向代理后，访客看到的通常是代理提供的地址，而不是源站地址。但只换 DNS 记录并不等于完成防护：旧记录、开放的管理端口或其他服务，都可能让源站重新暴露。理解源站IP隐藏与攻击面收敛方法，要同时处理“流量从哪里来”和“服务器还开放什么”两个问题。
先分清两种防护思路
代理接入：把公开入口移到代理层
反向代理或 CDN 位于访客与源站之间，负责接收请求，再按配置转发到后端。以 Nginx 反向代理为例，用户访问代理服务器的地址，Nginx 再把请求转给内网应用。这样能集中处理证书、访问规则和部分流量过滤，也能减少源站地址直接出现在常规访问路径中的机会。
它的边界也很明确：代理不会自动保护绕过代理直连源站的请求。如果源站仍对所有公网地址开放网站端口，知道地址的人仍可能直接访问。因此，代理接入是隐藏公开入口的基础，不是单独完成的访问控制。
服务收敛：减少可被连接的入口
服务收敛是检查服务器对外开放的端口和服务，只保留业务必需项。例如，网站可能需要开放 HTTPS，而 SSH 管理端口应限制在管理网络或指定来源；不再使用的测试服务应停止并关闭对应端口。端口少不代表绝对安全，但能减少需要维护和审查的暴露面。
两种思路解决的问题不同：代理接入调整流量路径；服务收敛限制谁能连接哪些服务。较完整的源站IP隐藏与攻击面收敛方法，通常需要二者配合。
按顺序实施，避免改完无法访问
- 盘点入口。列出域名、A 与 AAAA 记录、对外端口及依赖服务。除了主站，还要确认管理后台、文件下载或邮件服务是否与网站共用地址；这些服务未必能直接经过同一个代理。
- 先搭代理并验证。配置 CDN 或反向代理的回源地址，检查 HTTPS 证书、转发请求头和应用返回内容。先用测试域名或受控方式验证，再切换正式解析，避免把代理尚未就绪的请求导向错误位置。
- 让源站只接受可信入口。在云防火墙或主机防火墙中，将网站端口限制为代理服务商公布并维护的回源地址范围。若使用自建 Nginx，还要确认它监听的公网接口和上游服务配置符合预期。管理端口另设访问来源，不要因限制网站流量而误封运维通道。
- 检查地址泄露与协议覆盖。核对旧 DNS 记录、AAAA 记录和历史配置，确认 IPv6 与 IPv4 都遵循相同策略。若邮件、远程管理等服务需要直连，应单独评估其暴露风险，不要误把它们当成网站代理流量。
- 从外部复核并留好回退方案。在源站限制生效后，分别测试经代理访问和不经代理直连的结果；同时查看防火墙日志、应用日志与监控告警。变更前记录原有规则，便于出现故障时按步骤恢复。
容易忽略的配置细节
DNS 不等于防火墙。删除旧解析能减少常规查询暴露，但缓存、历史记录或其他服务仍可能揭示地址。保护源站的关键，是让源站网络规则拒绝非代理来源，而不是寄希望于地址无人知晓。
回源地址范围需要维护。代理服务的网络范围可能调整，规则应以服务商当前公布的资料为准，并纳入变更检查。若只添加新范围、不清理失效范围，规则会越来越宽；若更新不及时，则可能造成业务中断。
不要把所有服务塞进同一条规则。网站回源、SSH 管理、邮件收发可能有不同的网络路径和安全要求。按用途拆分规则并记录负责人，才能在排查时判断是代理配置、路由还是访问控制出了问题。这也是源站IP隐藏与攻击面收敛方法中容易被忽视的运维环节。
常见问题
接入 CDN 后，源站地址还会泄露吗？
有可能。旧 DNS 记录、其他直连服务或配置错误都可能暴露地址。还应通过防火墙限制回源来源，不能只依靠 CDN 解析。
小型网站一定要使用反向代理吗？
不一定。若托管平台已提供代理入口，可直接评估其接入方式；若应用直接部署在服务器上，自建反向代理也可行。选择取决于运维能力、业务依赖和可接受的复杂度。
源站只允许代理地址后，管理人员怎么登录？
为 SSH 等管理服务单独设置来源限制，例如仅允许受控管理网络访问；也可使用经审核的 VPN 或云平台管理通道。不要为了方便把管理端口重新开放给所有公网地址。
如何判断防护是否生效？
分别验证正常域名访问、源站直连和管理通道：正常请求应按预期经过代理，非代理来源的源站网站连接应被拒绝，获准的管理方式仍应可用。持续复核这些结果，才能让源站IP隐藏与攻击面收敛方法不止停留在一次性的配置变更。