frankenphp默认使用caddy的json日志格式，与nginx不兼容；需在caddyfile中配置log指令启用common_log格式以实现文本兼容，但存在时区、精度及时序对齐问题，且worker模式下长连接请求可能漏记。
FrankenPHP默认access日志格式和Nginx不兼容
FrankenPHP不输出Nginx风格的$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"，它用的是Caddy默认的JSON格式（含ts、request、status等字段），直接替换Nginx配置后，旧的日志分析脚本、ELK模板、监控告警规则全会失效。
用Caddyfile重写为类Nginx文本格式
FrankenPHP的HTTP服务层是Caddy，所以日志格式由Caddy控制。你不能改源码，但可以在Caddyfile里用log指令自定义输出：
log {
output file /var/log/frankenphp/access.log {
format single_field common_log
}
}
其中common_log是Caddy内置的Apache/Nginx兼容格式，输出形如：127.0.0.1 - - [04/Oct/2026:14:05:22 +0000] "GET /health HTTP/1.1" 200 2 "-" "curl/8.9.1"。
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
-
single_field确保每行一条日志，避免JSON嵌套干扰 - 别用
json或console格式，它们字段名和结构都不同 - 如果需要额外字段（比如
$upstream_response_time），FrankenPHP目前不暴露这类指标，Caddy原生也不支持，得换方案
注意时区和时间戳精度差异
Nginx默认用本地时区+秒级精度，Caddy的common_log用UTC+毫秒级ts再转成[dd/Mon/YYYY:HH:mm:ss Z]格式——看起来一样，但毫秒部分被截断，且固定UTC。如果你的监控依赖精确到毫秒的请求时间对齐（比如和PHP应用内microtime(true)打点比对），这个差异会导致时间漂移。
- 不建议强行改Caddy源码去加毫秒，维护成本高
- 更稳妥的做法是：在PHP应用里统一用
date('d/M/Y:H:i:s O')生成日志时间，和access日志对齐 - 所有日志采集端（如Filebeat）必须设
timezone: UTC，否则解析[... +0800]会错位
worker模式下access日志可能漏掉长连接请求
FrankenPHP在worker模式下复用PHP进程处理多个请求，但Caddy的access日志是每个HTTP事务独立打的——这点没问题。真正容易漏的是：当客户端用HTTP/2或HTTP/3建立长连接，然后发一堆请求，FrankenPHP内部可能因超时或worker重启导致最后几个请求没来得及写日志就退出了。
- 现象：压测时QPS很高，但access.log条数明显少于实际请求数
- 临时缓解：在
Caddyfile里加flush_interval 100ms，强制更频繁刷盘 - 根本解法：不要依赖access日志做精确计数，改用PHP内
register_shutdown_function()补全关键请求日志
FrankenPHP的日志问题核心不在“能不能仿Nginx”，而在于它把Web服务器和PHP运行时绑死了——你调不了Nginx那套log_format自由度，也绕不开Caddy的底层行为。最省事的路径是接受common_log格式，然后把下游所有解析逻辑适配过去，而不是试图让它变成另一个Nginx。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
