将Hostinger自定义域名绑定Azure App Service时遇400错误，求排查

从部署场景的常见问题逐一排查：

• 确认DNS记录的有效性与正确性

  • 用nslookup或dig工具检查解析结果：
    • 根域名（如example.com）：验证A记录返回的IP是否与App Service的公共IP完全一致（可在Azure门户App Service「概述」页查看）；同时确认TXT记录asuid.example.com的值与App Service域名验证时给出的字符串完全匹配（大小写敏感）。
    • 子域名（如www.example.com）：检查CNAME记录是否指向你的App Service域名（格式为<app-name>.azurewebsites.net），注意主机记录填子域名前缀（如www），记录值不要添加HTTP前缀或多余斜杠。
  • 等待DNS生效（通常5-15分钟，部分服务商耗时更久），可通过DNS查询工具确认全球解析状态。

• 验证Azure端域名状态
  登录Azure门户，进入目标App Service的「自定义域名」页面，查看添加的域名状态是否为已验证。若显示「未验证」，即便DNS配置正确也会触发400错误，需重新触发验证或检查DNS记录拼写。

• 检查证书绑定覆盖范围
  确认绑定的SSL证书**主题备用名称（SAN）**包含当前访问的域名（需同时覆盖根域名和子域名，比如example.com和www.example.com）。若证书仅绑定其中一个，访问未覆盖的域名会因证书不匹配报错。同时确认证书状态为「已绑定」且未过期。

• 清除缓存干扰

  • 清除浏览器缓存、Cookie，或用隐私窗口测试访问。
  • 本地执行ipconfig /flushdns（Windows）或sudo dscacheutil -flushcache（Mac）刷新DNS缓存。

• 检查HTTPS配置逻辑
  若开启了App Service「TLS/SSL设置」中的HTTPS Only，确保访问时使用https://前缀。部分HTTP跳转HTTPS的配置异常也可能触发400错误。

• 避免记录冲突
  根域名仅能通过A+TXT记录配置，不可同时配置CNAME记录（CNAME会覆盖A记录导致解析混乱）；子域名只需配置CNAME记录，无需重复设置A记录。

若以上步骤排查后仍有问题，可查看App Service「日志流」中的具体错误详情，日志会给出更明确的触发原因（如域名不匹配、证书无效等）。

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