阿里云国际站后付费 阿里云 ALB 绑定 WAF（Web应用防火墙）后出现的无限重定向（301/302 Loop）

阿里云 ALB 绑定 WAF 后出现的无限重定向，先别急着改代码

这类问题看起来像“浏览器坏了”或“应用出错了”，实际多半是 ALB、WAF、源站三层里至少有两层同时在做重定向。最常见的表现是 http 跳 https 后又被打回去，或者 www 和裸域名来回切换。排查时不要先改业务代码，先确认跳转到底是谁发出来的。

排查顺序建议固定下来：先看 Location 头，再看 HTTPS 跳转归属，最后查回源协议、Host 头和应用层重定向。

先判断 301/302 Loop 到底卡在哪一层

如果只是浏览器里一直转圈，不代表所有请求都循环。先用命令行和日志把链路拆开看，很多问题很快就能定位。

• 用 curl -I 分别访问 http 和 https，观察每次返回的 Location 是否在两个地址之间反复跳转。
• 对比 ALB 访问日志、WAF 日志和源站访问日志，确认第一跳是谁发出的。
• 在浏览器开发者工具里看 Network，重点看第一个 301/302 的目标地址是不是已经偏离了用户入口域名。

常见的循环形态

阿里云 ALB 绑定 WAF 后出现 301/302 Loop 的常见原因

1. ALB、WAF、应用三处都在做 HTTPS 跳转

这是最典型的场景。比如 ALB 已经把 http 301 到 https，WAF 侧又做了一次强制 HTTPS，应用代码里还写了访问到非加密请求就跳转。单看每一层都没错，叠起来就会互相触发。处理时要先定一个“唯一跳转点”，其余层不要再重复改协议。

2. 回源协议和前端协议不一致

前端用户是通过 https 访问，但 WAF 回源到 ALB 或源站时用了 http，应用看到的是未加密请求，就会再发起 301/302。很多框架会根据请求头里的协议判断是否重定向，所以要确认 WAF 到源站之间的协议策略与应用预期一致。

3. Host 头被改掉，应用误以为访问的是另一个域名

有些站点在代码里会把主域名、子域名、登录域名分开处理。绑定 WAF 后，如果回源 Host 没有保持原始访问域名，应用可能会把请求判定为“访问错域名”，然后自动跳到它认为正确的地址，最终形成循环。

4. 证书、域名和跳转目标没有统一

证书覆盖的是一个域名，跳转目标却写成另一个域名，或者证书只配了主域名但入口走的是带 www 的地址，这种情况在切流量、迁域名、做多环境合并时很常见。看起来像重定向问题，本质是入口域名没有统一。

5. 登录态和安全策略导致“看起来像重定向”

部分系统在 WAF 接入后会把 Cookie 的 Secure、SameSite、Domain 规则带出问题。用户一旦登录，应用又因为拿不到会话而跳回登录页，表面上像 302 Loop，实际是会话没有正确传递。这个问题在门户站、会员站、海外站点切换时更容易出现。

按这个顺序处理，通常能很快收敛

1. 先临时关闭一层跳转，只保留 ALB 或 WAF 其中一层负责 http 到 https 的重定向。
2. 确认 ALB 到 WAF、WAF 到源站都使用一致的协议策略，不要一层 https、一层 http 来回切。
3. 把应用里的强制跳转逻辑改成“仅在未加密访问时生效”，避免对已经到达 https 的请求再次重定向。
4. 检查证书覆盖的域名、重定向目标域名和用户实际入口域名是否完全一致。
5. 再用 curl 连续测试 http、https、www、裸域名和登录页，确认没有新的跳转链路被触发。

实务里最稳的做法是：只让一层负责“从 HTTP 到 HTTPS”的跳转，其他层只做透传和安全检测，不再重复改协议。

上线前先确认账号、认证、支付和资源条件

很多团队排查 301/302 Loop 时，只盯着配置页，却忽略了账号侧的问题。尤其是新购买资源、刚做实名认证、刚切企业主体、或者准备加购 WAF 规则时，账号和支付状态会直接影响你能不能及时改配置、扩容量、续费或提交工单。

• 账号购买前：先确认实名认证和企业认证是否已完成。资料不齐时，后续购买、扩容、开票、工单协助都会更慢，排障窗口会被拉长。
• 支付方式：提前确认信用卡、对公付款或预存余额是否可用，避免临时要加配额、续费或开新实例时卡在付款审核。
• 阿里云国际站后付费 风控审核：新账号、异地登录、主体信息不一致时，可能触发审核。建议把域名归属、联系人、账单信息提前统一，减少临时拦截。
• 阿里云国际站后付费 资源限制：检查监听器、转发规则、证书、回源地址、域名数量是否够用。多域名、多环境、多地区业务最容易在这里碰到限制。
• 成本控制：如果只是单站点，不要在 ALB、WAF、应用层同时保留多套重复跳转和重复规则。最后花在排障上的时间，往往比省下来的配置成本更高。

不同业务场景怎么选处理方式

常见错误

• 把 ALB 的重定向、WAF 的重定向、应用的重定向一起开着，结果互相打架。
• 改了跳转目标，却没同步证书和域名，导致浏览器继续判定为异常跳转。
• 只看首页不看登录页，首页正常了，登录还是循环。
• 只在自己电脑上测，没用 curl 和日志确认真实 Location 链路。
• 临时恢复访问后没有回头收敛规则，后面一加域名就再次复发。

阿里云国际站后付费 FAQ

Q1：WAF 绑定后只有某些页面循环，首页正常，为什么？

通常不是整站配置错了，而是某个页面单独触发了应用层重定向，比如登录页、语言切换页、带参数的回跳页。先看这个页面返回的第一个 Location，再追它为什么会把用户送回原页面。

Q2：能不能同时在 ALB 和应用层都做 301 跳转？

可以，但不建议。实际排障里，双重跳转最容易把问题放大。更稳的做法是选一层做统一入口，其他层只负责转发和业务判断。

Q3：如果是新账号，先办认证还是先买资源？

建议先把实名认证、企业认证、支付方式和账单信息准备好，再去买 ALB、WAF 或补充配额。这样在出现重定向、证书或规则调整时，不会因为账号审核或付款受限耽误处理。

Q4：临时止血最有效的方法是什么？

先停掉一层跳转，让访问路径变短，再逐层恢复。只要你能明确“谁在发第一个 301/302”，通常就能很快把循环断开。

最后给一个判断标准

如果你现在正准备买 ALB、绑定 WAF、做企业认证或者补充支付方式，先别急着把所有跳转都开上。先确认账号和资源是否可控，再把重定向职责固定到一层，后面运维会省很多事。对于已经上线的站点，先按日志把第一跳找出来，再决定是改 ALB、改 WAF，还是改应用。