Azure Functions多子域名映射下IoT设备HTTP请求超4分钟延迟问题问询

上下文信息 #

• 采用Linux计划，P1v3层级，1个实例，资源创建时已开启Always ON，使用Azure提供的SSL证书。
• C#编写的HTTP触发函数，匿名授权，GET请求，无阻塞调用的特殊属性或配置。
• 自定义域名映射，DNS解析由Cloudflare负责。
• 函数供IoT设备使用，设备检测到用户操作时发起HTTP请求。
• 涉及域名：example.company.com（存在问题）、example2.company.com（对比用域名）

观测结果 #

1. 同时映射example.company.com和example2.company.com到同一应用服务时，无论硬件使用哪个域名，服务触发均需4分钟以上。
2. 仅保留example2.company.com映射并移除example.company.com时，硬件调用服务恢复正常。
3. 使用调试工具调试设备固件，调用无延迟。
4. Wireshark抓包显示，硬件已无延迟发送请求，但请求迟迟未到达函数。
5. 测试10余台硬件设备，均出现相同问题。
6. 使用Postman或C#控制台应用发起相同请求，延迟<1秒，正常工作。
7. 从硬件所在办公室（同一ISP）用Postman调用正常，但硬件调用异常。

已执行操作 #

• 检查硬件固件及HTTP通信芯片，状态良好，且一年多未修改，未深入排查。
• 查看Azure遥测数据并联系Azure支持，已排除Azure服务本身作为根因的可能，需更具体排查提示。
• 检查Azure Function，已运行最新Azure Functions runtime，除硬件外其他调用均正常，未发现需优化项。
• 已提交工单至Cloudflare，确认是否为DNS解析问题，但单域名影响的情况不符合常理，等待回复。

进一步排查方向及解决方案建议 #

域名映射与配置排查 #

• 检查Azure应用服务的自定义域名绑定配置，确认两个域名的SSL绑定是否存在冲突，比如证书链配置差异、SNI设置异常。
• 临时添加第三个测试域名到同一应用服务，验证是否仅example.company.com存在绑定层面的特殊问题，还是多域名绑定触发了某种阈值。
• 核对Cloudflare针对两个域名的缓存规则、WAF规则、路由规则差异，确认example.company.com是否触发了隐形的流量拦截或排队机制。

HTTP交互细节对比 #

• 提取设备发起的HTTP请求与Postman请求的完整报文，对比User-Agent、请求头字段（Connection、Keep-Alive、Accept-Encoding等）、SSL/TLS版本、加密套件的差异，老旧设备的TLS配置可能在多域名场景下触发服务端特殊验证流程。
• 启用Azure应用服务的详细日志记录（HTTP日志、失败请求跟踪），查看请求到达服务端的时间点，确认是网络层丢包还是服务端接收后未及时转发到Function。
• 测试设备直接请求Azure Function的默认域名，验证是否自定义域名的多绑定才是问题根源。

网络路径追踪 #

• 在设备所在网络部署抓包工具，跟踪请求从设备发出后的完整路径：确认是否到达Cloudflare节点、是否转发到Azure、中间是否存在丢包或重传。
• 让设备使用公共DNS（如8.8.8.8）解析两个域名，验证是否本地ISP或Cloudflare返回的IP存在差异，导致设备连接到不同Azure边缘节点。
• 检查Cloudflare的流量加速配置，确认两个域名是否启用不同策略，多域名绑定后是否触发节点负载均衡异常。

临时应急方案 #

• 暂时仅保留example2.company.com的域名绑定，确保IoT设备服务正常运行。
• 若必须使用example.company.com，可尝试将其绑定到另一个同配置的Azure Function实例，验证是否单实例多域名绑定存在资源限制或冲突。

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