域名已经接入代理服务，访问者看到的还是源站页面，为什么仍要限制源站入口？关键在于：代理负责转发请求，但若源站公网地址仍接受任意来源连接，知道地址的人仍可能绕过代理直连。源站IP隐藏与回源策略配置必须一起完成，不能只改 DNS。
下面以一个常见场景说明：公开网站由代理层接收访问，再转发到云主机上的应用。具体控制台名称因服务商而异，操作原则相同。
先确认请求路径，再处理暴露面
正常链路应是“访客—代理入口—源站”。先盘点域名解析、源站公网地址、代理出口地址，以及健康检查和运维入口。检查常见记录时，留意网站主域名、子域名、邮件记录和历史解析；它们用途不同，不要为了隐藏网站源站而误删邮件服务所需记录。
还要检查应用日志、错误页面和公开配置是否回显源站地址。历史 DNS 记录可能被第三方缓存，单纯删除记录不能保证旧地址立刻无人知晓。若地址已经公开且风险较高，可更换源站公网地址，再按新地址重新配置访问规则。
四步落实回源限制
- 核对代理出口范围。从代理服务商的官方文档获取回源出口地址范围，并确认其更新方式。不要凭记忆填写网段；范围可能调整，需纳入日常维护。
- 设置防火墙白名单。在云安全组或主机防火墙中，只允许代理出口访问网站服务端口。若服务使用 HTTPS 回源，开放对应端口；管理端口则仅允许固定办公出口、VPN 或受控跳板机访问，避免用“所有地址”作为临时放行规则。
- 同步配置健康检查。代理的健康检查来源也必须能访问检查路径。按服务商公布的检查地址添加规则，并限制到所需端口和路径；否则可能出现页面看似已上线，代理却判定源站不可用的情况。
- 验证代理与直连两条路径。通过正式域名访问，确认页面、登录和必要接口正常；再从不在白名单内的网络尝试访问源站公网地址，预期应无法建立连接或不能获得应用内容。测试时避免影响生产业务。
访问策略还要覆盖协议与运维
回源加密不能只看浏览器一端
浏览器到代理使用 HTTPS，不代表代理到源站也自动加密。应检查回源协议、证书校验和主机名设置；若两段链路都使用 TLS，确认源站证书与回源主机名匹配。代理若需保留原始 Host 请求头，也应核对应用所需域名，避免错误路由到默认站点。
白名单维护要考虑变化
防火墙白名单比全网开放更安全，但若代理出口范围更新而规则未同步，合法请求也会中断。将地址范围变更纳入变更流程，先更新规则、验证健康检查，再切换流量；同时保留变更记录和回退方案。源站IP隐藏与回源策略配置不是一次性开关，而是 DNS、网络规则和运维流程的协同管理。
此外，网站代理不应成为管理后台的唯一保护措施。后台可单独限制访问来源，并使用多因素认证；确有远程维护需求时，优先经 VPN 或跳板机进入，不要为了方便把管理端口加入代理白名单。
上线前核对清单
- 公开 DNS 只指向预期的代理入口，未误改邮件等其他服务记录。
- 源站服务端口仅接受代理出口及明确批准的检查来源。
- 管理入口与网站回源规则分开设置。
- 回源加密、证书校验和 Host 设置与应用配置一致。
- 已验证正常访问、未授权直连和健康检查，并安排白名单更新责任人。
常见问题
只隐藏 DNS 记录够不够？
不够。地址可能从历史记录或其他配置中泄露；应同时限制源站入站访问。
能否直接封禁所有非代理来源？
可以作为网站入口策略，但须先确认健康检查、运维通道及其他合法业务依赖，并分别设置所需权限。
换了源站地址就不会再暴露吗？
不能保证。新地址仍可能因解析、配置或错误信息泄露，关键是持续限制可访问来源。
源站IP隐藏与回源策略配置由谁维护？
应由负责 DNS、云网络和应用发布的人员共同维护；代理出口范围变化时同步复核规则。
要让源站不直接暴露，核心不是追求地址绝对不可见，而是让未经授权的来源无法直连。把 DNS、白名单、回源加密和管理访问一并核查，才能让源站IP隐藏与回源策略配置真正落地。
