Azure Windows Server2019下IIS特定绑定返回503错误的排查咨询

已验证的可排除基准项 #

• 站点应用池无崩溃：系统日志无对应崩溃记录，服务器本地通过FQDN访问新站点完全正常，证明站点核心服务可正常加载
• 服务器主机侧防火墙无拦截：Windows防火墙已关闭
• 主机核心网络栈无全局故障：同主机绑定的旧IP站点从内网、外网访问均正常
• 你观测到的核心异常特征：新站点仅在服务器本地访问正常，其他主机（无论内网还是外网）访问均返回503，且IIS站点日志无对应503记录

符合所有异常特征的高概率故障点（按排查优先级排序） #

1. 服务器本地配置类（不经过外部网络组件也会触发，匹配“本地正常、跨主机报错、IIS日志无记录”特征） #

• 新站点绑定的独立IP未在物理网卡上完成正式绑定
  Windows的环回适配器会优先响应本地所有同网段的IP访问请求，即便IP没有在物理网卡上正式启用，本地访问也能正常通；但其他主机发往该IP的流量到达物理网卡时，会因为没有对应的IP配置导致TCP栈无监听套接字，直接由系统返回连接重置/网关层转换为503错误，请求不会递交给IIS，因此站点日志无记录。
  验证方式：
  • 执行ipconfig /all，确认192.1.1.6是在物理网卡的IPv4地址列表中，而非仅存在于环回适配器配置
  • 执行netstat -ano | findstr :443，确认443端口的监听条目明确绑定在192.1.1.6上，而非仅绑定在旧站点IP、127.0.0.1或所有网卡通配上
• IIS SSL证书绑定条目错位
  若配置新站点绑定时误开启了“需要服务器名称指示（SNI）”选项，会导致HTTP.sys核心的SSL证书绑定条目错位：跨主机访问时TLS握手阶段就会被HTTP.sys拦截终止，不会进入站点请求处理流程，自然不会在站点日志中留痕。
  验证方式：执行netsh http show sslcert，对比192.1.1.5、192.1.1.6两个IP对应的证书绑定条目，确认192.1.1.6的条目匹配新站点的独立证书，无交叉错位
• 请求被拦截在IIS请求处理流程的前置阶段
  你之前仅核查了站点本身的访问日志，这类被HTTP.sys核心拦截的503错误不会写入站点日志，仅会记录在系统全局HTTP错误日志中，默认路径为C:\Windows\System32\LogFiles\HTTPERR，可直接查看该日志定位拦截原因。

2. 网络路径类（推翻“内网访问必然直连服务器”的主观判定） #

• 内网访问流量实际被引流经过了前置网络组件
  Azure虚拟网络的自定义路由表、PFSense的静态路由策略可能把指向192.1.1.6的内网流量下一跳指向PFSense或应用网关，而非直连服务器网卡。这类场景下如果前置组件针对新站点的健康检查不通过（比如健康检查路径匹配错误、TLS证书校验不通过），组件会直接把后端节点从负载均衡池剔除，所有请求会被组件直接返回503，根本不会到达服务器，因此IIS无日志记录。
  验证方式：从内网测试主机执行tracert api.newcompanyname.com，如果路由路径中出现PFSense、应用网关的内网IP，即可证明流量并非直连服务器。
• PFSense未针对新站点IP配置对应的NAT/放行规则
  跨主机的流量只要路径经过PFSense，未匹配到允许的规则时，PFSense会直接返回网关层503错误，不会把流量转发到服务器。

推荐排查顺序 #

• 优先执行服务器本地的网卡IP检查、端口监听检查、全局HTTPERR日志查看，全流程10分钟内即可定位问题，完全匹配你观测到的所有异常特征
• 其次验证内网访问的实际路由路径，避免主观假设流量直连
• 最后再排查应用网关、Traffic Manager的后端健康检查配置

内容的提问来源于stack exchange，提问作者TRock