Syncthing 怎么用？从设备配对到文件同步的实用笔记

Syncthing 系列目录

• Syncthing 怎么用？从设备配对到文件同步的实用笔记
• 用 Docker 部署 Syncthing：Compose、端口和目录映射避坑
• Syncthing 多设备怎么配？对等网络、星型拓扑和引入者
• Android 上怎么用 Syncthing？Syncthing-Fork 配置与照片备份
• Syncthing 多设备多文件夹怎么管理？拓扑、命名和版本控制
• Syncthing 如何同步 iPhone 照片到电脑或 NAS

Syncthing 适合用来做多设备之间的点对点文件同步。它不是传统网盘，也不是把所有数据先上传到某个中心服务器再下载回来，而是让已授权的设备直接交换文件。

如果你正在考虑用它同步 Markdown 笔记、照片备份、配置文件、家庭 NAS 目录，重点不是“能不能同步”，而是先理解它的几个基本概念：设备、文件夹、设备 ID、同步方向、发现方式和冲突处理。

Syncthing 解决什么问题

Syncthing 的核心场景是：你有两台或多台设备，希望它们之间保持某个目录一致。

典型例子：

• Windows 桌面和笔记本之间同步工作资料。
• 手机和 NAS 之间同步照片或文档。
• 多台 Linux 服务器之间同步配置样例、脚本或小型资料目录。
• Obsidian、Joplin 外部附件、Markdown 笔记目录在多设备间同步。

它更适合“自己控制设备和数据”的同步场景。如果你需要多人权限管理、在线预览、网页协作编辑，传统网盘或文档协作平台会更合适。

第一次启动后会发生什么

官方入门文档建议把两台机器并行配置。Syncthing 里，一台机器叫一个 device。你当前正在配置的机器是 local device，另一台要同步的机器是 remote device。

第一次启动 Syncthing 时，它会生成配置文件、加密密钥和设备 ID，并默认在本机打开 Web GUI：

1

http://127.0.0.1:8384/

这个 Web GUI 是日常配置入口。官方文档里也提到，默认会创建一个 Default Folder，通常对应用户目录下的 Sync 文件夹。你可以先用它测试，也可以后面删除并添加自己的目录。

设备 ID 是配对基础

Syncthing 的设备配对靠 device ID。

每台设备首次启动时都会生成自己的密钥，设备 ID 可以理解为这个设备证书的可读指纹。两个设备只有互相添加了对方的设备 ID，才会建立连接并同步。

实际操作顺序通常是：

1. 在两台设备上都启动 Syncthing。
2. 分别打开 Web GUI。
3. 在 A 上添加 B 的 device ID。
4. 在 B 上添加 A 的 device ID。
5. 选择要共享的文件夹。
6. 保存后等待两边连接。

设备 ID 不需要像密码一样保密，但也不要随便把自己的同步拓扑公开到不必要的地方。真正需要保护的是设备私钥、Web GUI 管理权限和同步目录本身。

文件夹不是自动全盘同步

Syncthing 同步的是你明确添加的 folder，不会默认同步整台机器。

每个文件夹都有自己的路径、ID、共享设备和同步类型。常见做法是按用途拆分：

• notes/：Markdown 笔记。
• photos-inbox/：手机照片中转。
• docs/：多设备文档目录。
• scripts/：小脚本和配置样例。

不要一开始就同步过大的系统目录、下载目录或混杂目录。目录越复杂，冲突、忽略规则、权限差异和扫描成本越容易变成长期维护问题。

三种常见文件夹类型

官方文档里把文件夹类型分得很清楚。实际使用时，先理解这三种就够了。

Send & Receive

这是默认模式。这个文件夹既发送本机变更，也接收其他设备变更。

适合：

• 多台电脑共同编辑笔记。
• 多设备共同维护文档。
• 普通双向同步目录。

如果两台设备同时改了同一个文件，Syncthing 会产生冲突文件，而不是直接静默覆盖。

Send Only

这个模式下，本机像“参考副本”。它会向其他设备发送变化，但不会应用其他设备传来的变化。

适合：

• 主设备向备份设备分发文件。
• 希望某台机器上的目录状态作为准。
• 不希望远端修改反向影响本机。

如果远端发生变化，本机可能显示 out of sync。此时 Web GUI 会提供 Override Changes，用本机状态覆盖集群里的其他状态。这个按钮要谨慎点，因为它会把本机当前状态强制推给其他设备。

Receive Only

这个模式和 Send Only 相反。它接收集群里的变更，但本地改动不会再发给其他设备。

适合：

• 备份目标。
• 只读镜像。
• 不希望本地误操作污染主同步目录的设备。

如果本地出现修改，Web GUI 会提示 Revert Local Changes，可以把本地变更撤回到集群版本。

防火墙和端口要先看

Syncthing 能通过发现服务、NAT、relay 等机制让设备互相找到，但网络越清楚，连接越稳定。

官方防火墙文档列出的关键端口是：

1
2
3

22000/TCP
22000/UDP
21027/UDP

其中：

• 22000/TCP 用于 TCP 同步协议流量。
• 22000/UDP 用于 QUIC 同步协议流量。
• 21027/UDP 用于本地发现广播或组播。

如果设备在同一个局域网内，但一直发现不了，优先检查本机防火墙、路由器隔离、Wi-Fi 和 LAN 是否被分到不同网段。

如果设备跨公网或跨 NAT，能做端口转发时，直接连接通常比 relay 更好。没有端口转发时，relay 也可能让设备连上，但性能会比直连差。

Linux 上如果使用 ufw 并安装了对应包，可以用：

1
2

sudo ufw allow syncthing
sudo ufw status verbose

Web GUI 默认只监听本机的 127.0.0.1:8384。如果要远程访问 GUI，可以改成 0.0.0.0:8384，但这意味着管理界面对外暴露，必须同时考虑密码、HTTPS、反向代理或 SSH 隧道。普通家庭场景下，更推荐用 SSH 隧道访问远端 GUI。

.stignore 要放在同步根目录

如果有些文件不想同步，可以在同步文件夹根目录创建 .stignore。

注意几个细节：

• .stignore 必须放在同步文件夹的根目录。
• 规则相对于同步根目录生效。
• .stignore 本身不会同步到其他设备。
• 文件内容应使用 UTF-8 编码。

一个简单例子：

1
2
3
4
5

(?d).DS_Store
node_modules
*.tmp
cache/**
!/cache/keep.txt

(?d) 的作用是：当这些被忽略文件阻止目录删除时，允许 Syncthing 删除它们。适合 .DS_Store 这类系统自动生成文件。

感叹号 ! 是反向规则，用来把某些文件重新纳入同步。但反向规则可能导致 Syncthing 遍历本来会忽略的目录。规则很多时，最好先从简单规则开始，不要一上来写成复杂的黑白名单系统。

文件版本不是本地撤销

Syncthing 支持文件版本保留，但它的语义容易误解。

官方文档强调，版本保留是“接收远端变更时，把旧版本归档”。也就是说，如果 A 开启了版本保留，B 修改了文件并同步到 A，A 会把被替换的旧文件保存起来。但如果 A 自己本地修改了文件，Syncthing 不能替 A 保存修改前的版本。

常见版本策略包括：

• Trash Can File Versioning：类似回收站，被远端删除或替换的文件移到 .stversions。
• Simple File Versioning：保留固定数量的历史版本。
• Staggered File Versioning：按时间间隔保留版本，越旧越稀疏。
• External File Versioning：交给外部脚本处理。

如果你用 Syncthing 同步重要文档，建议至少在备份目标设备上开启简单版本或回收站版本。它不能代替完整备份，但能减少误删和误覆盖的损失。

同步冲突如何产生

Syncthing 会识别冲突。两个设备同时修改同一个文件，并且内容不同，就可能生成类似这样的冲突文件：

1

filename.sync-conflict-date-time-modifiedBy.ext

这比静默覆盖安全，但也意味着你要定期清理冲突文件。

容易产生冲突的场景：

• 多设备同时打开同一份 Markdown 笔记。
• 应用程序自动写入同一个状态文件。
• 同步 .obsidian/workspace.json 这类设备状态文件。
• Windows、macOS、Android 之间出现大小写文件名差异。

如果同步笔记，建议把正文、附件和模板同步；工作区状态、缓存、插件临时文件要谨慎处理，必要时放进 .stignore。

安全边界：数据加密，但使用痕迹不可完全隐藏

Syncthing 的安全目标之一是：未授权设备不能加入同步集群，传输中的文件内容不能被旁路监听者读取。

官方安全文档说明，设备间流量由 TLS 保护，连接建立时会检查设备证书指纹是否在允许列表中。换句话说，只有双方配置了彼此的设备 ID，才会真正建立同步关系。

但这不等于“使用 Syncthing 这件事不可见”。例如：

• 开启全局发现时，设备会向发现服务器公告设备 ID 和监听端口。
• 本地发现会在局域网内发送广播或组播。
• relay 服务器会知道连接设备的 device ID，但不能解密同步内容。
• Web GUI 如果对外开放，会暴露这台机器运行了 Syncthing。

所以安全建议很直接：

• 不要把 Web GUI 暴露到公网，除非你明确做好认证和加密。
• 只添加你信任的设备。
• 重要目录配合系统磁盘加密或单独备份。
• 不需要全局发现、relay 或自动升级时，可以按场景关闭，但要接受连接便利性下降。

不受信任设备加密适合什么场景

Syncthing 还支持 Untrusted / Encrypted Devices。这个功能可以让某个不受信任设备只保存加密后的数据。

一个典型场景是：你有一台云服务器或外部机器，希望它参与同步、承担中转或备份角色，但不希望它看到明文文件。可信设备向它发送数据时，会使用文件夹密码加密；其他可信设备拿到同样密码后，可以从这个不受信任设备同步并解密。

但官方文档也提醒，这个功能仍应视为 beta / testing。它适合有明确需求的人谨慎使用，不建议一开始就作为主同步方案。

需要特别记住：

• 文件数据、文件名、时间、哈希和目录结构会被保护。
• 文件夹 ID、标签和大致文件大小不属于完整保护范围。
• 密码和 folder ID 要可靠保存。
• 不受信任设备上的文件夹类型要设为 Receive Encrypted。

如果只是家庭 NAS、自己的电脑和手机之间同步，通常先用普通可信设备模式，把系统登录、磁盘加密和备份做好，会更容易维护。

实用配置建议

如果你准备用 Syncthing 长期同步笔记或文档，可以按这个思路配置：

1. 每类资料单独建文件夹，不要混在一个超大目录里。
2. 主力电脑使用 Send & Receive。
3. NAS 或备份机可以考虑 Receive Only，并开启文件版本。
4. 手机端只同步必要目录，不要同步应用缓存目录。
5. 用 .stignore 排除缓存、临时文件、工作区状态文件。
6. 局域网内优先保证 22000/TCP、22000/UDP、21027/UDP 可用。
7. Web GUI 尽量保持本机监听，需要远程管理时优先用 SSH 隧道。
8. 重要资料不要只依赖同步，仍然需要独立备份。

适合和不适合

Syncthing 适合：

• 你希望数据主要留在自己的设备上。
• 你愿意理解设备配对、同步目录和冲突处理。
• 你有 NAS、家用服务器或多台个人设备。
• 你想同步 Markdown、照片中转、脚本、轻量文档。

Syncthing 不太适合：

• 需要多人在线协作编辑。
• 需要网页端文件预览和分享链接。
• 需要细粒度团队权限。
• 不想处理任何网络、防火墙和冲突问题。

它更像一个可靠的“设备间同步层”，而不是完整的云盘产品。用得好，Syncthing 可以把 NAS、电脑、手机连成一个可控的数据网络；用得太随意，也可能因为冲突、误删、忽略规则和网络配置变成维护负担。

参考资料

• Syncthing Documentation
• Getting Started
• Syncthing Configuration
• Folder Types
• Firewall Setup
• Ignoring Files
• File Versioning
• Understanding Synchronization
• Security Principles
• Untrusted (Encrypted) Devices