Kratos框架本身不处理HTTP重定向循环，问题必然源于其前端网关、反向代理（如Nginx）、负载均衡器或客户端调用错误；Kratos默认不主动返回301/302，所有重定向行为均由外部组件或开发者显式代码触发。
Kratos 框架本身不处理 HTTP 重定向循环（ERR_TOO_MANY_REDIRECTS），它既不是反向代理，也不参与 TLS 终止或 Web 层的协议跳转逻辑。这类问题根本不在 Kratos 的职责范围内。
如果你在用 Kratos 服务时遇到重定向死循环，几乎可以确定：问题出在 Kratos 前面的网关、反向代理（如 Nginx、Traefik）、负载均衡器，或者客户端（比如浏览器、前端应用）对 Kratos 接口的调用方式有误。
为什么 Kratos 不会自己造成重定向循环？
Kratos 是一个 Go 编写的微服务框架，其 HTTP Server 默认行为是：
- 收到请求后直接处理，不主动发起
301/302跳转（除非你代码里显式写了w.WriteHeader(http.StatusMovedPermanently)或调用了http.Redirect）； - 所有路由由
http.ServeMux或第三方路由器（如gorilla/mux）匹配，不内置重定向中间件； - 框架提供的中间件（如认证、日志、熔断）均不修改响应状态码为重定向类；
- 即使启用了 HTTPS 强制跳转，也是靠外部组件（如 Nginx 的
return 301 https://$host$request_uri;）完成，Kratos 进程内无此逻辑。
常见导致 Kratos 接口出现重定向循环的场景
实际排查中，以下几类配置最容易引发循环：
-
Nginx配置了return 301 https://$host$request_uri;，但后端 Kratos 服务又通过X-Forwarded-Proto: http错误判断协议，导致业务层再次跳转回 HTTPS； - 前端 SPA 应用（如 Vue/React）把 Kratos 的 API 地址配成
http://api.example.com，而该域名实际只监听 HTTPS 端口，Nginx 自动 301 跳转，但前端未适配跳转后的新地址，反复请求原 HTTP 地址； - Kratos 服务被部署在 Kubernetes 中，Ingress Controller（如 Nginx Ingress）开启了
ssl-redirect: true，但后端服务健康检查路径（如/healthz）返回了 302，触发 Ingress 无限重试； - 你在 Kratos 的 middleware 或 handler 里手动调用了
http.Redirect(w, r, "/login", http.StatusFound)，且未加条件判断（例如未检查r.Header.Get("X-Forwarded-Proto") == "https"），导致在 HTTPS 入口下仍不断跳转。
怎么快速验证是不是 Kratos 导致的？
绕过所有中间层，直连 Kratos 服务端口做测试：
- 用
curl -v http://localhost:8000/ping（假设 Kratos 监听本地 8000）——看是否返回200且无Location头； - 再用
curl -v https://localhost:8000/ping（如果启用了 TLS）——确认是否报错或跳转； - 对比加上
-H "X-Forwarded-Proto: https"后的行为，判断是否是中间件误判协议； - 检查 Kratos 项目中是否有自定义的 redirect 逻辑，搜索关键词：
http.Redirect、StatusMovedPermanently、StatusFound、SetHeader("Location",。
真正需要关注的，从来不是“Kratos 怎么解决”，而是“谁在往 Kratos 前面塞重定向”。绝大多数时候，删掉 Nginx 里那行 return 301，或者修正前端的 API 基地址，问题就消失了。
