把域名解析到代理或加速服务，并不等于源站已经隐藏：旧 DNS 记录、公开配置文件或其他服务暴露的地址，都可能让访问者绕过前置入口。可靠的源站隐藏与回源策略，需要同时限制“谁能连到源站”和“源站如何确认请求来自可信入口”。
先收紧源站入口，而不只是隐藏地址
先盘点承载网站的公网 IPv4、IPv6 地址、对外端口，以及管理面板、文件服务等是否共用同一主机。若网站只应经由反向代理访问，就在源站防火墙或云平台安全组中设置访问控制列表，仅放行代理服务公布的回源地址范围和必要端口；网站常见端口为 80 和 443，实际应以业务配置为准。
与“只把 DNS 改到代理”相比，网络层限制能直接阻断对源站地址的任意连接，效果更明确；代价是需要维护代理出口地址清单。代理地址范围发生变化时，应同步更新规则。若源站启用了 IPv6，却只限制 IPv4，攻击者仍可能通过 IPv6 直连，因此两种协议都要检查。SSH 等管理入口应使用单独的来源限制，不要因网站回源需要而一并开放。
再确认回源请求确实经过可信链路
传输加密与身份校验各有作用
在代理到源站的连接上启用 TLS，可以加密传输，并通过证书校验避免连接到错误主机。但仅有加密不必然代表请求来自指定代理：还应按所用平台能力配置客户端证书（mTLS）或等效的回源身份验证。客户端证书能提供双向身份校验，但需要管理证书签发、轮换和失效；自定义密钥请求头配置较简单，却应避免泄露，并在源站验证后及时剥离，不能把它当作网络访问限制的替代品。
还要核对 TLS 证书名称、代理使用的主机名和源站虚拟主机配置是否一致。不要为了消除证书报错而关闭证书校验。若代理会传递客户端地址等请求头，源站只应信任来自已允许代理的连接所携带的值，避免把外部用户自行提交的同名请求头误当作真实信息。
按顺序实施并从外部验证
- 记录现状：整理 DNS 的 A、AAAA 记录、源站地址、开放端口和当前代理出口范围；检查邮件、文件下载等独立服务是否有不同的访问需求。
- 先配置回源：在代理侧设定源站地址、目标端口、TLS 校验和健康检查。健康检查应访问能反映服务状态的路径，并确认不会因认证或主机名设置而误判。
- 限制直连：在源站入口规则中仅允许必要的代理地址访问网站端口，再确认管理入口仍可由获准网络维护。规则应覆盖 IPv4 与 IPv6。
- 启用身份校验：根据代理与源站能力部署 mTLS 或安全的请求凭据；通过测试环境或维护窗口确认正常回源可用，再逐步收紧规则。
- 做两类测试：经正常域名访问，确认页面、证书和健康检查正常；再从不在允许范围的外部网络尝试连接源站地址，确认直连被拒绝。检查源站日志，区分代理回源、健康探测和管理流量。
预留故障恢复，但不要留下长期绕过口
上线前应明确代理出口变更、证书过期、健康检查失败时由谁处理，以及如何恢复规则。临时放宽访问范围只能用于排障，并应记录原因、限定时间和及时回收；不要长期允许所有来源访问来换取表面可用性。若业务允许，也可将源站放在不直接暴露公网的网络中，由受控通道接入，但这会增加网络规划与运维要求。
源站隐藏与回源策略不是一次性改 DNS，而是入口限制、身份验证和持续核查的组合。定期检查 DNS 记录、IPv6 暴露、代理地址清单及源站日志，才能发现配置漂移；同时保留可审计的变更记录，便于故障时快速定位。
常见问题
隐藏源站后，旧地址还能被访问吗？
可能。只要源站仍接受任意公网连接，知道地址的人仍可尝试直连；应在源站侧限制来源并验证回源身份。
只用请求头密钥够不够？
不够稳妥。密钥可能泄露，宜与网络来源限制或 mTLS 配合，并支持轮换和撤销。
源站需要开放 80 端口吗？
视回源方式而定。若代理使用 HTTPS 回源，通常可不开放 80；应以实际健康检查、跳转和业务配置为准。
如何确认配置没有误伤正常流量？
分别验证代理访问、健康检查和管理操作，并查看源站日志；规则变更宜分阶段实施并保留回退方案。