最稳方式是在Caddyfile的80端口server块中用return 301 https://{host}{uri}实现跳转，FrankenPHP不处理协议跳转，须由Caddy路由控制，HTTPS块启用php_server且禁用CDN强制HTTPS以防循环重定向。
Caddyfile 里加 return 301 是最稳的方式
FrankenPHP 自身不处理协议跳转，它依赖底层 Caddy 的路由和重定向能力。所有 HTTP → HTTPS 跳转必须写在 Caddyfile 中，且只能在监听 80 端口的 server 块里做。不要试图在 PHP 层用 header() 或中间件拦截——FrankenPHP 启动后请求已进入 PHP 上下文，此时跳转既晚又不可靠，还可能和 Caddy 的自动 HTTPS 冲突。
实操建议：
- 确保你的
Caddyfile包含两个独立的yourdomain.comserver 块：一个监听:80（仅跳转），一个监听:443（处理 HTTPS 流量） - 80 端口块里只写
return 301 https://{host}{uri}，别加php_server或其他处理器 - 443 端口块里启用
php_server，并确认 TLS 已由 Caddy 自动管理（默认开启） - 如果域名带 www 和非 www，两个都要在
server_name里显式列出，或用通配符*.example.com
别开「自动 HTTPS」再手动跳转，否则 ERR_TOO_MANY_REDIRECTS
Caddy 默认开启自动 HTTPS（ACME + Let’s Encrypt），但它只对 443 端口生效。如果你同时开了自动 HTTPS 又在 :80 块里写 redir 或 handle 转发到 HTTPS，通常不会出问题；但一旦你额外配置了反向代理、CDN 或自定义 TLS 设置，就极易触发循环重定向——浏览器看到 301 → 发起新 HTTPS 请求 → Caddy 又检查到没走 443 → 再 301……最终报 ERR_TOO_MANY_REDIRECTS。
排查要点：
立即学习“PHP免费学习笔记（深入）”；
- 用
curl -I http://yoursite.com看响应头是否只有一次Location:，且状态码是301 - 检查 Caddy 日志：
caddy log或journalctl -u caddy -f，看是否有重复匹配 :80 块的日志行 - 禁用 CDN 的「强制 HTTPS」开关（如 Cloudflare 的 “Always Use HTTPS”），让它只做 TLS 终止，把跳转逻辑完全交给 Caddy
开发环境 localhost 不要跳 HTTPS
本地用 localhost:8080 或 127.0.0.1 跑 FrankenPHP 时，Caddy 无法申请有效证书，硬跳 HTTPS 会导致连接失败或浏览器警告。直接在 Caddyfile 里加 host 判断是最干净的解法。
示例配置片段：
http://localhost:8080, http://127.0.0.1:8080 {
respond "HTTP only for dev" 200
}
example.com, www.example.com {
@http {
host example.com
host www.example.com
not protocol https
}
handle @http {
redir https://{host}{uri} 301
}
php_server
}
注意：not protocol https 比检查端口更准确，能覆盖 HTTP/2 over TLS 等边界情况；respond 块专用于本地调试，不参与生产部署。
FrankenPHP 的 frankenphp 全局块不影响跳转逻辑
很多人误以为在 { frankenphp { ... } } 里能配置协议跳转，其实这个块只控制 PHP 运行时行为（线程池、内存、日志等），和 HTTP 路由完全无关。它甚至不感知请求协议——那是 Caddy 的事。所以以下写法毫无意义：
{ frankenphp { redirect_https true } }
真正起作用的永远只有 Caddy 的 handle、redir、return 和 match 指令。FrankenPHP 就是个插件，不是 Web 服务器主体。
最后提醒一句：FrankenPHP 的 HTTP/3 支持默认只在 HTTPS 下启用，HTTP 请求压根不会协商 HTTP/3。所以跳转不是“可选项”，而是启用现代协议的前提——这点容易被忽略，尤其当你只测了 curl 却没开浏览器开发者工具看 Network 标签页里的 Protocol 列。
