源站隐藏怎么做？暴露面到mTLS回源的5道关口

源站隐藏是分层防御机制，而非单一操作，很多团队第一反应是换IP，但若未厘清问题落在哪一层，换IP只是将同一份暴露面重新暴露一次。2026年8月官方文档持续更新回源鉴权指南，直指挂载CDN后依然“被打瘫源站”的行业普遍误区。五道递进关口各有分工：暴露面清理降低被发现概率，解析层收口消除旁路入口，网络层白名单实现基础隔离，传输层mTLS完成确定性拦截，边缘承载则负责抵御容量型洪水。

源站被直连打时，先问哪三个问题再动手

当遭遇源站被直连攻击时，盲目调整架构往往无效，需通过决策树定位根因。首先判断源站IP泄露途径：是被第三方通过历史DNS、证书透明日志、邮件记录或测试子域扫描发现，还是本身就有子域直接解析到了源站？其次检查网络层状态：源站是否仅放行了回源IP段，还是仍然对公网开放80/443端口？最后分析攻击流量特征：打入的是应用层请求，还是直接将上行链路压满的容量型洪水？

这三条分支分别指向后续的暴露面清理、网络隔离与边缘承载环节。对于静态站点、动态API和非HTTP业务，其失效表现各有不同，但核心逻辑一致：只有准确识别当前防御体系的薄弱层级，才能避免在错误的方向上消耗资源。

历史DNS、证书透明日志与测试子域为什么替源站说话

暴露面的产生往往源于配置疏漏而非技术缺陷。域名接入CDN之前的历史解析记录会被第三方数据库长期保留，成为攻击者的情报来源。证书透明日志会公开所有签发过的子域名，许多团队忽略了对staging、后台管理等非生产环境的证书覆盖，导致这些子域直接指向源站真实IP。此外，邮件服务的MX与SPF记录、以及未走CDN的独立IP服务同样会泄露底层基础设施信息。

自查动作应聚焦于全量资产梳理：枚举所有子域并逐个检查解析结果是否落在边缘节点段；核对证书签发名称中是否存在未接入CDN的子域；确认对外发信服务是否与Web服务共用同一台物理机或IP。这一关口的核心价值在于降低源站被主动发现的概率，属于被动防御范畴，无法直接拦截已发起的连接请求。

解析层收口：把仍指向源站的A记录一条条排掉

解析层的严谨性决定了源站入口的封闭程度。首要任务是将所有对外提供服务的子域统一切换为CDN CNAME记录，确保流量必经边缘节点。其次，对于管理面板、监控探针、灰度发布等非公开子域，应从公网DNS解析中彻底移除，或改为仅内网可达的私有解析方案。同时，需收窄泛解析范围，防止任意未知子域自动解析至源站IP。

执行核对时，应以权威DNS的记录清单为准，逐条比对解析归属，而非依赖记忆或局部截图。接入CDN后需进行二次复查，确认无记录回落至源站。此环节失效的典型现象是主站访问正常，但某个不起眼的测试子域被扫描器命中后，引发源站IP泄露后的应急处理与修复步骤需求，进而导致源站整机带宽耗尽或服务宕机。

网络层回源白名单：只放行回源出口，比换IP先生效

CISA与FBI在2024年发布的官方指南明确指出，单机本地带宽无法抗衡分布式容量型与协议型洪水，必须采用云端高防CDN或清洗网络前置吸收流量，并对源站实施严格的网络层隔离。这意味着源站侧的安全组或主机防火墙应仅允许CDN边缘回源IP段的访问，拒绝其余所有源地址。

落地时需确保白名单覆盖完整的回源出口网段，并建立跟随变更更新的机制。SSH、数据库及管理端口应单独限制至办公出口或跳板机。即便配置了白名单，仍可能出现被直连的情况，常见原因包括网段不全、云厂商安全组与主机防火墙规则冲突、以及存在监听公网端口的旁路服务。

上述表格提供了初步排查方向，具体需结合日志分析。若需了解整体架构设计，CDN安全加速的相关实践可作为参考。

mTLS回源鉴权：让源站只响应携带边缘证书的握手

如果说白名单是IP层面的门禁，那么mTLS（双向TLS）则是连接本身的身份证校验。Authenticated Origin Pulls（AOP）机制通过要求客户端在TLS握手中提供特定的私有证书，确保源站仅响应来自合法CDN边缘节点的请求。即使攻击者探测到源站真实IP，由于无法伪造受信任的CA签发的客户端证书，其在握手阶段即被拒绝，从而有效阻断绕过CDN的直连行为。

配置思路是在源站Web服务（如NGINX）上启用客户端证书校验，并指定信任的CA列表。未通过校验的连接不会进入业务处理流程。上线前务必在灰度域名或非高峰时段验证，避免边缘之外的健康检查、监控回源被误拒。需注意，白名单防御的是IP伪装，而鉴权防御的是即使源IP合法但非预期客户端的连接，二者互补而非替代。具体的客户端证书校验的配置思路细节，应严格遵循所用服务端与CDN服务商的官方文档指引。

隐藏做到位仍要有边缘承载：洪水打的是链路不是应用

前四道关口主要解决“被找到”和“被直连”的问题，但在面对超大容量网络层攻击时，若缺乏边缘承载能力，源站依然会瘫痪。容量型洪水在流量到达Web服务之前，就已填满机房入口带宽和网络设备队列，此时源站上的白名单、限流和鉴权规则尚未生效便已失去意义。官方指南据此强调将清洗前置到云端分布式网络的重要性。

据第三方威胁报告显示，超大规模攻击已成为常态化威胁，反射放大仍是主要形态。因此，按单机带宽峰值采购防御资源的传统思路已不再适用。明确的分工结论是：前四关降低被攻击者发现和直连的可能性，第五关决定在被大流量冲击时业务能否存活。若遇到突发大流量，快速评估无感接入高防CDN配置流程以争取缓冲时间。

五道关口的失效现象与上线前逐项验证

为确保源站隐藏策略的有效性，需执行以下验证清单。每次架构调整或域名变更后，均需重跑此清单。

1. 枚举全部子域并确认解析归属：使用通用工具查询所有子域解析结果。失效现象：冷门子域被扫到后整机被打。
2. 核对证书签发名称与邮件相关记录：检查CT日志中的域名是否均已接入CDN。失效现象：换IP后很快又被找到。
3. 非回源网络直连测试：从家庭宽带或非白名单IP尝试访问源站IP的80/443端口。失效现象：能拿到与主站相同的页面内容。
4. 伪造Host头直连测试：构造包含正常域名的Host头，直接向源站IP发送请求。失效现象：源站正常返回业务数据。
5. 开启鉴权后验证握手拒绝：使用curl不带客户端证书访问源站HTTPS端口。失效现象：连接成功建立，或健康检查报错。

常见问题

高防CDN接入后源站IP还会暴露吗

是的，接入CDN并不保证源站IP绝对不可见。如果未清理历史DNS记录、未收敛测试子域解析，或未配置严格的网络层白名单，攻击者仍可通过测绘手段获取真实IP。隐藏的核心是增加发现成本，而非物理隔绝。

怎么查自己网站的源站IP有没有暴露

可通过查询历史DNS解析库、检索证书透明日志（CT Logs）中的子域名、检查邮件SPF/MX记录关联IP，以及使用非CDN网络环境直接Ping或Telnet源站候选IP来验证。若任一渠道能连通且返回业务内容，即视为暴露。

安全组已配置为何仍被直连

首先检查白名单是否覆盖了CDN提供商最新的全量回源IP段，其次排查云厂商安全组与操作系统防火墙规则是否存在优先级冲突，最后确认是否有未纳入CDN管理的旁路服务（如内部API网关）仍监听公网端口。

NGINX 源站如何强制 mTLS 校验

需在源站服务器（如NGINX/Apache）配置SSL客户端证书校验指令，加载CDN提供的专用CA公钥文件，并将验证模式设为强制。同时需确保CDN控制台已启用Authenticated Origin Pulls功能，并在边缘节点部署对应的客户端私钥。

换过一次IP之后还被攻击的原因

这通常意味着暴露面清理不彻底。旧IP可能已被收录进历史DNS缓存或扫描器指纹库，或者新IP所在的网段特征、TTL设置、甚至网站源码中的硬编码链接泄露了新地址。若不切断泄露源头，单纯更换IP仅是延缓攻击时间。

建议按文中清单先做一次暴露面与直连自查，再决定是否换IP；如果确认已具备白名单与鉴权条件、缺的是边缘侧的承载与固定回源出口，可结合 RockCloud 的高防CDN与源站保护能力评估接入方式。