日志位置与审计日志：排障时先看哪里
默认日志在哪
官方 FAQ 的答案分层：
- 默认打到 stdout——命令行前台运行时直接看控制台；
- Windows 上默认同时写文件：配置目录里的
syncthing.log（--logfile参数可自定义路径）； - systemd 管理的进程：日志进 journal（
journalctl --user -u syncthing）； - GUI 集成包：可能由集成层代管。
没有终端时找路径的两个入口：命令行 syncthing --paths；管理界面 Help → About → Paths 标签（配置、数据库、日志各自的实际位置一目了然）。
日志里常见的信号
| 日志片段 | 含义 |
|---|---|
My ID: ... | 本机设备 ID |
Established secure connection ... at ... | 与某设备建立连接（含通道类型） |
Failed initial index exchange ... | 首次索引交换失败——排查[连接问题(../03-设备配对/05-pairing-failed.md) |
Folder marker missing | 文件夹标记丢失，见[对应 FAQ(../10-常见问题/04-faq-marker-missing.md) |
Detected NAT type: ... | NAT 类型，影响直连成功率 |
database is corrupt | 索引库损坏，见下文 |
为什么任务管理器里有两个进程
Windows 用户常见疑问：程序怎么跑了两份？官方 FAQ 的解释：一个是监视进程（monitor），负责捕获日志、管理重启与自升级，另一个是真正干活的进程。这是设计而非异常。
--audit：比日志更细的变更流水
GUI 里的 Recent Changes 只显示本进程启动以来的变更（见[界面导览(../02-安装与首次启动/05-gui-tour.md)）。需要持久的完整活动记录时用 --audit 参数启动：程序把 JSON 格式的事件流写进 audit-日期_时间.log。注意官方说明的边界：重连后的审计只见「最新一次变化」——离线期间对方设备的多步修改在索引交换后被压缩为一个结果。
数据库损坏的处理
日志出现数据库损坏时（官方说几乎总是硬件问题——坏内存或坏盘）：停止程序 → 删除数据目录里的索引数据库 → 重启。代价是所有共享文件夹重新全量哈希。官方同时提醒：查明硬件隐患，别只删库了事。
调试级别的日志
连接类疑难杂症在 INFO 级看不清时，可用环境变量提高特定模块的日志级别（官方文档 STTRACE 一节有模块清单），排完记得改回来——调试日志量很大。