Azure Front Door 请求直接访问独立后端的原因及配置问题咨询

问题1：客户端获取后端主机URL的常见原因 #

你遇到的情况90%以上是单页应用的配置问题，核心可能性有两个：

• Angular应用的打包环境配置里，API请求的基准地址（baseURL）被硬编码为了后端的真实域名，而非*Azure Front Door（AFD）*的公网访问域名。初始的静态资源（html、js）是从AFD拉取的，但js代码里已经写死了后续API请求要直接发给后端真实地址，自然不会走AFD。你提到从GET options预检请求开始就直接访问后端，基本可以排除重定向导致的问题，大概率是这个原因。
• 后端服务返回了带真实后端域名的3xx重定向响应，或者响应体、响应头中携带了真实后端地址，浏览器拿到后会直接基于这个地址发起后续请求，绕开AFD。

问题2：配置所有请求走负载均衡的方法 #

按优先级操作即可：

1. 修改Angular应用的环境配置，把所有API请求的基准地址统一替换为AFD的公网域名，禁止任何代码里直接写后端真实地址。
2. 配置AFD的路由规则，匹配所有路径（包含静态资源路径、API路径）转发到你的后端池，按需配置路径重写规则即可。
3. 调整后端服务配置，所有重定向、响应内容中涉及的域名统一用相对路径，或者显式写AFD的域名；也可以通过AFD的规则引擎，自动把后端响应里的真实后端域名替换为AFD域名，避免泄露。
4. 把CORS、缓存等公共配置统一迁移到AFD层面实现，不需要后端单独处理。

问题3：架构合理性与异常行为判断 #

• 全量请求经过AFD是完全合理的，也是Azure推荐的标准用法：AFD的核心能力（全局负载均衡、自动故障转移、WAF防护、流量调度）都需要所有流量经过它才能生效，还能统一收敛公网暴露面，降低安全风险。
• 当前遇到的404需手动刷新的情况不属于预期行为：本质是后续请求绕开了AFD，AFD无法感知请求也无法执行故障转移逻辑，只有所有流量都走AFD时，AFD才能实时检测后端健康状态，自动把请求转发到正常的后端节点，用户完全无感知，不需要手动刷新。

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