跨境站点接入加速服务后，用户请求会先经过边缘节点，再由边缘节点按需访问源站。若 DNS 指向正确，但源站仍允许任何人直连，隐藏地址就只是表面功夫。做好跨境业务源站隐藏与加速配置，应依次处理 DNS、回源和缓存，并在每一步验证访问路径。
第一步：先让 DNS 指向边缘节点
在域名服务商处，将对外提供服务的主机名按加速服务商要求配置为 CNAME，或使用其指定的 DNS 接入方式。根域名是否支持 CNAME、是否需要别名记录，取决于 DNS 服务商；不要自行套用其他平台的记录类型。邮件用的 MX、验证用的 TXT 等记录应保留，避免误删导致邮件或域名验证异常。
- 先记录现有 DNS 记录和 TTL，便于发现问题时核对或回退。
- 按服务商控制台给出的目标配置业务主机名，等待解析缓存逐步更新。TTL 较短有利于较快切换，但不能保证所有递归解析器同时更新。
- 确认新请求已到边缘节点，再逐步停止对外发布旧的源站地址。注意：DNS 切换本身不会阻止访客使用已知 IP 直连源站。
如曾公开过源站 IP，可检查旧 DNS 记录、公开配置文件及应用响应中是否遗留该地址。切换后还要观察一段时间的访问日志，不能仅凭 DNS 查询结果认定源站已隐藏。
第二步：收紧回源，阻断绕过边缘节点
回源是边缘节点取回源站内容的过程。应先在源站防火墙或云网络访问规则中，仅允许所用边缘服务的官方出口地址访问网站端口；地址范围以服务商当前文档为准，并设置更新流程。管理端口应另行限制来源，避免与公开网站端口混在一条宽泛规则里。
核对主机名与加密连接
在加速平台填写源站地址时，优先使用专用回源主机名，并确认它解析到真实源站，而不是重新指向加速域名形成循环。回源连接应启用 TLS，并核对证书覆盖的主机名、有效期及平台的校验设置。若源站仍需为其他服务开放公网访问，应按实际来源拆分规则，而不是直接放开全部流量。
变更前先保留可用的管理通道和回退规则。验证时分别测试经边缘节点访问与直连源站：前者应正常返回；后者在网络策略允许的测试环境外应被拒绝。日志中若仍出现非边缘来源请求，应检查遗漏的端口、IPv6 规则或其他未纳入控制的入口。
第三步：最后设置缓存，避免加速变成内容错误
缓存决定边缘节点在什么条件下复用响应。静态图片、字体和带版本号的脚本通常适合较长缓存；登录状态、购物车、账户页面以及个性化 API 响应，通常应绕过缓存或使用严格的缓存键。具体时长由更新频率、回滚能力和业务要求决定，不宜对整个站点一刀切。
- 先按文件类型或明确的 URL 路径建立规则，不要把所有 HTML 都设为长期缓存。
- 检查源站的 Cache-Control、Set-Cookie 等响应头，并核对边缘平台对这些头部的处理方式。
- 发布内容后，对受影响的路径执行定向清除；范围过大的清除会让边缘节点重新集中回源。
- 比较边缘响应与源站响应，确认语言、地区、登录状态等差异没有被错误复用。
对于按国家或语言变化的页面，只有在缓存键确实包含对应区分条件时才适合共享缓存；否则可能把一种语言或地区的内容返回给另一类访客。缓存命中率也要结合源站负载和响应正确性观察，不能单独作为配置成功的依据。
按顺序验证，出现异常时定位对应环节
先看 DNS 是否指向预期边缘入口，再看边缘节点能否通过指定回源主机名连接源站，最后检查缓存状态与响应内容。这种分层检查能减少同时改动多项规则造成的误判，也是跨境业务源站隐藏与加速配置上线后的基本验收方法。若出现证书错误，优先核对回源 TLS 与主机名；若直连仍成功，检查源站访问控制；若内容不更新，则检查缓存规则和清除范围。
常见问题
只把 DNS 改到加速服务商，源站就隐藏了吗？
没有。旧地址可能已被记录，且源站若接受任意公网连接，仍可绕过边缘节点访问；还需限制回源来源并检查地址泄露。
源站防火墙应该允许哪些地址？
仅允许当前使用的边缘服务官方回源地址范围，并按其文档维护变更。不同服务商和接入方式的范围不同，不宜照搬其他平台的列表。
所有页面都适合缓存吗？
不适合。静态资源通常更适合缓存，包含账户状态、Cookie 或个性化数据的响应应谨慎处理，必要时绕过缓存。
修改后多久能生效？
DNS 更新受记录 TTL 和递归解析器缓存影响，边缘规则则按服务商的发布机制生效。应以实际解析和请求验证为准，不预设统一时间。
按 DNS、回源、缓存逐层配置并验证，才能让跨境业务源站隐藏与加速配置同时兼顾访问速度、源站保护和内容准确性。