Azure应用网关阻止重定向：保持浏览器地址不变转发请求

首先得捋清楚问题根源：你的AppService（部署在www.test.com）收到Application Gateway转发的请求时，请求里的Host头是www.test.org（毕竟用户访问的是这个域名），而AppService默认会校验请求Host头是否匹配它已绑定的域名，不匹配就会触发301重定向到自身的默认域名www.test.com。你之前用WAF2层成功实现，核心就是靠WAF修改了请求的Host头，让后端服务“误以为”请求是发给它认可的域名的。

下面给你两个可行的解决方案：

方案一：用WAF自定义规则修改请求Host头（和你之前的成功案例逻辑一致） #

• 登录Azure门户找到你的Application Gateway资源
• 进入「Web应用程序防火墙」→「规则集」，选中你在用的WAF2规则集（比如OWASP 3.2）
• 点击「自定义规则」→「添加自定义规则」，新建规则：
  • 规则名称：比如RewriteHostToTestCom
  • 优先级：设一个比默认规则高的数值（比如100，数值越小优先级越高）
  • 匹配条件：选「请求头」→「Host」，匹配运算符选「等于」，值填www.test.org
  • 操作：选「修改请求头」→「设置」，头名称填Host，值填www.test.com
• 保存规则后等AG配置更新完成，再访问www.test.org，地址栏就会保持不变，请求也能正常转发到后端AppService

方案二：给AppService绑定www.test.org域名（更直接的方式） #

如果业务允许把这个域名绑定到目标AppService，这是最省心的方法：

• 登录Azure门户找到你的AppService资源
• 进入「自定义域名」→「添加自定义域名」，输入www.test.org
• 按照提示完成域名所有权验证（因为你的DNS已经指向AG的IP，确保验证所需的DNS记录配置正确）
• 绑定完成后，AppService会认可www.test.org这个Host头，自然就不会触发301重定向了

补充说明 #

你之前用WAF2层成功的原因，就是利用了WAF的请求头修改能力，把用户请求的Host头替换成了AppService认可的域名，让后端服务觉得请求是直接发给它的默认域名的，所以不会重定向。如果你的AG是标准层而非WAF层，默认没有自定义规则修改请求头的能力，这时候要么升级到WAF层，要么用方案二来解决。

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