Coolify 通过 Cloudflare Tunnel 访问资源出现 TOO_MANY_REDIRECTS 怎么排查【免费下载链接】coolifyAn open-source, self-hostable PaaS alternative to Vercel, Heroku Netlify that lets you easily deploy static sites, databases, full-stack applications and 280 one-click services on your own servers.项目地址: https://gitcode.com/GitHub_Trending/co/coolify当资源通过 Cloudflare Tunnel 的 all-resource 方式接入时公网 HTTPS 请求会经由http://localhost:80进入 Coolify 的 proxy。如果资源域名以https://保存而该资源同时开启了 HTTP 到 HTTPS 的重定向隧道送来的请求会反复被打回 HTTP 入口浏览器端最终报出TOO_MANY_REDIRECTS。这篇排查文章基于 Coolify 的设计说明 External TLS HTTP Redirect Design讲明这个循环的成因、判定方法和修复操作。先判断是否属于这个重定向环TOO_MANY_REDIRECTS在这个场景下的前提是三个条件同时成立Cloudflare Tunnel 把公网流量转发到 Coolify 服务器的 HTTP 入口http://localhost:80TLS 由 Cloudflare 侧终结资源域名在 Coolify 中以https://形式保存该资源的 Redirect HTTP to HTTPS 处于开启状态默认开启。设计文档指出早期文档给出的规避办法是把公网域名存成http://。这能让重定向环消失但会歪曲公网 URL并可能产生不正确的 secure cookie、OAuth 回调地址和 canonical 链接。正确的做法是域名继续存https://然后针对该资源关闭重定向。如果资源不经过 Cloudflare、直接暴露在公网或者 Cloudflare 使用的是 Full / Full (Strict) SSL流量以 HTTPS 到达 Coolify则不要关闭该开关TOO_MANY_REDIRECTS也另有原因不在本文范围内。在 Domains 页面关闭重定向对普通应用和 Docker Compose 应用控制项位于应用设置中的 Domains 页面只有当资源至少存在一个https://域名时页面才会显示名为Redirect HTTP to HTTPS的开关可选值为Enabled/Disabled对应的设置项是ApplicationSetting::is_force_https_enabled见 domains.blade.php。页面自带的帮助文本是Disable only when Cloudflare Tunnel or another proxy connects to Coolify over HTTP. Keep enabled when Cloudflare uses Full or Full (Strict) SSL.操作路径打开出现问题的应用的 Domains 页面确认域名以https://保存将Redirect HTTP to HTTPS设为Disabled。对 Service服务中的每个应用服务Domains 页面对应位置提供同样的控制项forceHttpsRedirects.{appId}见 service/domains.blade.php逐服务关闭纯数据库类的服务条目不显示该控制项。保存后的行为由设计文档定义改动会按 boolean 校验走与域配置相同的授权检查并标记 proxy 配置已变更、跟随现有的保存/重新部署流程生效——也就是说保存后需要等一次重新部署代理配置才会更新。验证修复结果设计文档给出的手动冒烟流程是本文的验证标准把 Cloudflare Tunnel 的主机名路由到http://localhost:80资源域名保存为https://关闭重定向后访问公网 HTTPS 地址应能直接加载不再出现重定向循环。自动测试也覆盖了对应行为ApplicationDomainsTest.php 断言 HTTPS 域名下控制项可见、修改后is_force_https_enabled持久化为false且 HTTP-only 域名下控制项隐藏。边界与限制默认行为不变控制项默认Enabled服务应用的is_force_https_enabled在数据库层面默认true迁移见 2026_08_17_000000_add_is_force_https_enabled_to_service_applications_table.php已存在的资源迁移后行为保持不变。不要为绕过循环把域名改存为http://这会把错误的 URL 传给应用的 cookie、OAuth 与 canonical 逻辑。控制项只对含https://域名的资源显示隐藏时不会重置已保存的值。预览部署继承父应用当前的重定向设置改父应用设置后预览部署一并生效。关闭该开关只移除 redirect 这一项代理行为现有的路径剥离、gzip、认证、noindex、www/非 www 中间件等保持原样。如果关闭开关并等待重新部署后仍然出现TOO_MANY_REDIRECTS说明流量并非经 HTTP 入口进入例如 Cloudflare 配置为 Full/Full (Strict)此时应把开关重新打开需要回到 Cloudflare 侧检查 TLS 模式与隧道路由指向。【免费下载链接】coolifyAn open-source, self-hostable PaaS alternative to Vercel, Heroku Netlify that lets you easily deploy static sites, databases, full-stack applications and 280 one-click services on your own servers.项目地址: https://gitcode.com/GitHub_Trending/co/coolify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Coolify 通过 Cloudflare Tunnel 访问资源出现 TOO_MANY_REDIRECTS 怎么排查？
Coolify 通过 Cloudflare Tunnel 访问资源出现 TOO_MANY_REDIRECTS 怎么排查【免费下载链接】coolifyAn open-source, self-hostable PaaS alternative to Vercel, Heroku Netlify that lets you easily deploy static sites, databases, full-stack applications and 280 one-click services on your own servers.项目地址: https://gitcode.com/GitHub_Trending/co/coolify当资源通过 Cloudflare Tunnel 的 all-resource 方式接入时公网 HTTPS 请求会经由http://localhost:80进入 Coolify 的 proxy。如果资源域名以https://保存而该资源同时开启了 HTTP 到 HTTPS 的重定向隧道送来的请求会反复被打回 HTTP 入口浏览器端最终报出TOO_MANY_REDIRECTS。这篇排查文章基于 Coolify 的设计说明 External TLS HTTP Redirect Design讲明这个循环的成因、判定方法和修复操作。先判断是否属于这个重定向环TOO_MANY_REDIRECTS在这个场景下的前提是三个条件同时成立Cloudflare Tunnel 把公网流量转发到 Coolify 服务器的 HTTP 入口http://localhost:80TLS 由 Cloudflare 侧终结资源域名在 Coolify 中以https://形式保存该资源的 Redirect HTTP to HTTPS 处于开启状态默认开启。设计文档指出早期文档给出的规避办法是把公网域名存成http://。这能让重定向环消失但会歪曲公网 URL并可能产生不正确的 secure cookie、OAuth 回调地址和 canonical 链接。正确的做法是域名继续存https://然后针对该资源关闭重定向。如果资源不经过 Cloudflare、直接暴露在公网或者 Cloudflare 使用的是 Full / Full (Strict) SSL流量以 HTTPS 到达 Coolify则不要关闭该开关TOO_MANY_REDIRECTS也另有原因不在本文范围内。在 Domains 页面关闭重定向对普通应用和 Docker Compose 应用控制项位于应用设置中的 Domains 页面只有当资源至少存在一个https://域名时页面才会显示名为Redirect HTTP to HTTPS的开关可选值为Enabled/Disabled对应的设置项是ApplicationSetting::is_force_https_enabled见 domains.blade.php。页面自带的帮助文本是Disable only when Cloudflare Tunnel or another proxy connects to Coolify over HTTP. Keep enabled when Cloudflare uses Full or Full (Strict) SSL.操作路径打开出现问题的应用的 Domains 页面确认域名以https://保存将Redirect HTTP to HTTPS设为Disabled。对 Service服务中的每个应用服务Domains 页面对应位置提供同样的控制项forceHttpsRedirects.{appId}见 service/domains.blade.php逐服务关闭纯数据库类的服务条目不显示该控制项。保存后的行为由设计文档定义改动会按 boolean 校验走与域配置相同的授权检查并标记 proxy 配置已变更、跟随现有的保存/重新部署流程生效——也就是说保存后需要等一次重新部署代理配置才会更新。验证修复结果设计文档给出的手动冒烟流程是本文的验证标准把 Cloudflare Tunnel 的主机名路由到http://localhost:80资源域名保存为https://关闭重定向后访问公网 HTTPS 地址应能直接加载不再出现重定向循环。自动测试也覆盖了对应行为ApplicationDomainsTest.php 断言 HTTPS 域名下控制项可见、修改后is_force_https_enabled持久化为false且 HTTP-only 域名下控制项隐藏。边界与限制默认行为不变控制项默认Enabled服务应用的is_force_https_enabled在数据库层面默认true迁移见 2026_08_17_000000_add_is_force_https_enabled_to_service_applications_table.php已存在的资源迁移后行为保持不变。不要为绕过循环把域名改存为http://这会把错误的 URL 传给应用的 cookie、OAuth 与 canonical 逻辑。控制项只对含https://域名的资源显示隐藏时不会重置已保存的值。预览部署继承父应用当前的重定向设置改父应用设置后预览部署一并生效。关闭该开关只移除 redirect 这一项代理行为现有的路径剥离、gzip、认证、noindex、www/非 www 中间件等保持原样。如果关闭开关并等待重新部署后仍然出现TOO_MANY_REDIRECTS说明流量并非经 HTTP 入口进入例如 Cloudflare 配置为 Full/Full (Strict)此时应把开关重新打开需要回到 Cloudflare 侧检查 TLS 模式与隧道路由指向。【免费下载链接】coolifyAn open-source, self-hostable PaaS alternative to Vercel, Heroku Netlify that lets you easily deploy static sites, databases, full-stack applications and 280 one-click services on your own servers.项目地址: https://gitcode.com/GitHub_Trending/co/coolify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考