FAL_SERVER启动失败主因是端口占用、配置路径错误或日志目录不可写；FAL_CLIENT断链多因参数不匹配、时钟不同步或资源限制。需逐项检查端口、权限、参数优先级、时间同步及资源配额。
FAL_SERVER 启动失败导致 client 连不上
常见现象是 fal_client 初始化时卡住或报 connection refused，但 fal_server 进程根本没起来。根本原因通常是端口被占、配置路径错误，或日志目录不可写。
-
FAL_SERVER默认监听0.0.0.0:8080，启动前先用lsof -i :8080或netstat -tuln | grep 8080确认端口空闲 -
FAL_SERVER的--log-dir路径必须存在且当前用户有写权限，否则静默退出——查ps aux | grep FAL_SERVER会发现进程不存在 - 不要把
FAL_SERVER配置成后台服务后就不管日志输出，加--log-level debug启动一次，看控制台是否打印server started on :8080
FAL_CLIENT 日志断链的典型配置错位
断链不是网络问题，而是 FAL_CLIENT 和 FAL_SERVER 对不上节奏：client 发送日志太快，server 没来得及 ACK，client 就重连，形成“发—断—重连—再断”循环。
-
FAL_CLIENT的--batch-size默认是 100，如果单条日志很大（比如含 trace_id + 大 JSON），实际每批数据超 1MB，server 默认max-body-size=512KB直接 413，client 误判为连接中断 - 必须同步调大两端参数：
FAL_SERVER --max-body-size 2097152（2MB），FAL_CLIENT --batch-size 20（减小单批体积） -
FAL_CLIENT --reconnect-interval别设太短（如 100ms），server 启动慢或 GC 时会触发密集重连风暴，建议设为1000（1 秒）
环境变量与命令行参数优先级混乱
FAL_SERVER 和 FAL_CLIENT 都支持环境变量和命令行参数，但命令行会覆盖环境变量——这点容易被忽略，导致改了 .env 文件却没生效。
- 生效顺序固定：
命令行参数 > 环境变量 > 内置默认值，比如设置了FAL_SERVER_PORT=9000环境变量，又在启动时加--port 8080，最终监听的是 8080 - 检查当前生效值最直接的方式是启动时加
--print-config（如果支持），或用strace -e trace=execve看实际传入的参数 - 容器部署时尤其注意：Dockerfile 中
ENV设置的变量，可能被docker run -e覆盖，而docker run --entrypoint后的参数又会覆盖ENTRYPOINT里的默认命令
日志时间戳不一致引发的断链假象
client 发的日志带本地时间戳，server 存储时用自身系统时间做归档目录（如 /logs/2024/06/15/），若 client 和 server 时钟差超过 5 分钟，server 可能把新日志写进“昨天”的目录，监控脚本扫不到最新文件，误报断链。
- 强制所有节点跑
chronyd或ntpd，禁用 systemd-timesyncd（精度不够） -
FAL_CLIENT加--use-server-time（如果支持），让 server 统一分配时间戳；不支持的话，client 端必须定期校时，不能只靠 NTP 启动时同步一次 - 别依赖日志文件名判断“最新”，用
stat -c '%Y' /path/to/log取 mtime 更可靠
