请求经过边缘代理后，源站看到的连接来源往往是边缘节点，而不是访客设备。若边缘层和主机防火墙各自配置、没有按实际流量路径对齐，可能出现正常请求被拦截，或源站仍能绕过边缘直接访问。做好边缘防护与主机防火墙协同配置，关键是先画清路径，再决定每一层允许什么流量。
先确认流量经过哪些节点
常见网站请求路径是：访客到边缘服务，边缘服务完成缓存、访问控制或 Web 应用防火墙检查，再转发到源站主机。主机防火墙看到的通常是边缘出口地址；应用日志中的访客地址则可能通过可信代理头传递。两者含义不同，不能把应用记录的访客地址直接当成主机防火墙的连接来源。
先列出公开业务端口、源站地址、边缘回源地址，以及管理入口。若应用还依赖独立的邮件、对象存储或第三方接口，也要确认其连接方向：出站访问通常不应误写成入站放行规则。非 HTTP 类服务则需单独判断边缘产品是否支持对应协议，不能默认所有流量都经过 Web 代理。
按层设置规则，避免重复放行
边缘层负责面向访客的筛选
在边缘控制台配置网站域名、证书、访问策略和应用层防护。公开业务只开放实际需要的服务；管理页面优先限制访问来源或通过身份验证保护。边缘层策略解决访客请求是否应被接收，主机防火墙不必重复实现复杂的应用内容判断。
主机层负责保护源站入口
源站防火墙只允许边缘服务回源所需的地址和端口访问业务服务，例如网站实际使用的加密 Web 端口。边缘地址段可能变更，应从服务商的公开配置渠道获取并按变更流程维护，不要凭记忆手工抄写长期使用。管理端口应只对 VPN、堡垒机或明确的管理网段开放，不要因为业务端口需要公网可达，就一并开放管理入口。
这类边缘防护与主机防火墙协同配置有一个重要前提：源站不能被任意访客绕过边缘直连。若源站必须保留其他合法入口，应为该入口单独设定来源和用途，而不是扩大业务端口的允许范围。
按顺序实施并验证
- 记录现状：整理边缘回源设置、主机现有规则、业务端口和管理通道，并保存可恢复的配置。
- 确认地址与协议：核对边缘回源地址范围、传输协议、健康检查方式及 IPv4、IPv6 是否都在使用。只配置其中一种地址族，可能留下另一条可达路径。
- 先加允许规则：确保边缘节点能够访问源站业务端口，同时保留必要的管理通道；再逐步收紧其他来源。
- 测试真实路径：分别检查经边缘访问、从非授权网络直连源站、管理入口访问和健康检查。查看边缘日志、主机防火墙日志及应用日志，确认每一层看到的来源符合预期。
- 启用并观察：在流量较低且便于处理故障的时段应用收紧后的规则。若出现误拦截，先按记录回退相关变更，再定位具体端口、地址族或回源配置。
常见失误与处理
- 信任代理头过宽：应用只有在连接确实来自可信边缘时，才应采信用于还原访客地址的代理头。否则，外部请求可能伪造该字段。
- 边缘地址更新后未同步：定期核对地址清单和防火墙规则；有自动化更新机制时，也要记录变更并检查失败告警。
- 只测网页，不测旁路：HTTPS 页面正常不代表源站已不可直连，还需从不在允许清单中的网络检查源站入口。
- 规则无日志或无回滚：排错时应能区分拒绝发生在边缘还是主机层，并保留撤销变更的途径。
归根结底，边缘防护与主机防火墙协同配置不是简单地把两处规则叠加，而是让边缘层筛选访客、主机层限制源站入口，并用日志和测试证明流量确实按预期经过。业务拓扑或边缘地址发生变化时，应同步复核规则。
常见问题
主机防火墙能否只允许边缘地址访问网站端口？
如果业务请求确实全部经边缘回源，通常可以这样限制；先确认健康检查、IPv6 和其他合法入口也已纳入设计。
边缘层和主机层是否需要配置完全相同的拦截规则？
不需要。边缘层更适合处理面向访客的应用请求筛选，主机层重点限制网络连接和源站暴露，两层职责应互补。
怎样确认源站没有被绕过？
从不在主机允许清单中的外部网络直接访问源站地址，并结合防火墙日志确认连接被拒绝；测试时避免影响正常业务。