Azure App Service访问同私有网络Azure SQL随机超时问题排查

问题现象 #

• 部署架构：App Service 为 P3v2 规格，已开启 Always On 配置；对接同平台托管的 SQL Server，规格为 1200 DTU，二者通过私有网络通信。
• 异常表现：近期出现无规律查询超时，触发超时的查询本身正常执行耗时仅1ms；异常无明确触发条件，即使无业务负载、仅发起单个请求也可能触发，99%的请求可正常执行，剩余1%请求会无诱因触发40秒超时，异常触发频率约为每40次数据库请求出现1次，瞬态错误率远高于常规运维场景水平。
• 资源状态：业务运行峰值期DTU占用从未超过20%，异常发生时DTU占用仅约1%，数据库整体性能表现优异，几乎无闲置打开的数据库连接，不存在连接池耗尽问题。
• 时间线：问题首次出现于两周前微软执行平台维护后，异常发生时段业务侧未部署任何新代码，初步怀疑为Azure骨干网链路异常。

捕获的异常信息 #

英文原报错：

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.) A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

中文释义：建立SQL Server连接时发生网络相关或实例特定错误，服务器未找到或不可访问，请验证实例名称正确性、确认SQL Server已配置允许远程连接。（provider: TCP Provider, error: 0 - 连接尝试失败，因连接方在超时周期内未正确响应，或已建立连接因主机无响应失败。）

排查与修复方案 #

• 第一优先级补业务层瞬态错误重试兜底
  这是Azure平台网络瞬态错误的通用应对方案，无需等平台侧排查即可落地。针对error 0的TCP连接超时错误，配置3-5次指数退避重试，首次重试间隔1秒，后续间隔逐次翻倍，禁止使用固定间隔重试避免触发限流。如果使用ADO.NET原生连接，直接在连接字符串中添加参数：ConnectRetryCount=3;ConnectRetryInterval=1000;Connection Timeout=15，将原40秒的单连接超时下调到15秒，配合快速重试用户侧基本无感知；如果使用ORM框架，直接开启框架内置的数据库执行重试策略，将TCP超时错误纳入重试覆盖范围。
  注意：重试次数不要超过5次，避免底层链路大面积故障时重试流量放大故障影响。
• 校验平台侧网络配置
  先排查App Service与SQL Server间VNet的NSG规则、自定义路由表，确认不存在静默丢弃TCP报文的错配规则，将链路TCP空闲超时调整为30分钟，避免中间网络设备静默断开空闲连接。可临时将SQL Server的连接策略从默认的Redirect模式切换为Proxy模式测试错误率变化：Redirect模式下客户端首次建连后会直连数据库计算节点的临时端口，平台维护后路由策略同步不完整时极易出现随机黑洞路由；Proxy模式下所有流量经过SQL网关转发，链路稳定性更高，如果切换后错误率直接下降，可基本定位为Redirect路由同步异常。
• 平台侧根因定位
  开启App Service与SQL Server的双向网络流日志、连接诊断，捕获超时发生时的TCP握手状态，确认SYN报文发送后是否无回包、丢包发生的链路位置。如果业务层重试、网络配置调整后错误率仍未下降，直接提交Azure支持工单，明确说明问题首次出现于平台维护后、业务侧无变更、资源无瓶颈，附上异常时间点、源目IP、错误码信息，要求核查对应区域骨干网到SQL私有端点的路由表、负载均衡健康检查配置——这类固定概率的无诱因连接超时，大概率是平台维护后部分网络节点路由表未同步完成，或负载均衡将流量转发至异常节点导致。

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