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：
|
|
这个 Web GUI 是日常配置入口。官方文档里也提到，默认会创建一个 Default Folder，通常对应用户目录下的 Sync 文件夹。你可以先用它测试，也可以后面删除并添加自己的目录。
设备 ID 是配对基础
Syncthing 的设备配对靠 device ID。
每台设备首次启动时都会生成自己的密钥，设备 ID 可以理解为这个设备证书的可读指纹。两个设备只有互相添加了对方的设备 ID，才会建立连接并同步。
实际操作顺序通常是：
- 在两台设备上都启动 Syncthing。
- 分别打开 Web GUI。
- 在 A 上添加 B 的 device ID。
- 在 B 上添加 A 的 device ID。
- 选择要共享的文件夹。
- 保存后等待两边连接。
设备 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 等机制让设备互相找到，但网络越清楚，连接越稳定。
官方防火墙文档列出的关键端口是：
|
|
其中：
22000/TCP用于 TCP 同步协议流量。22000/UDP用于 QUIC 同步协议流量。21027/UDP用于本地发现广播或组播。
如果设备在同一个局域网内，但一直发现不了，优先检查本机防火墙、路由器隔离、Wi-Fi 和 LAN 是否被分到不同网段。
如果设备跨公网或跨 NAT，能做端口转发时，直接连接通常比 relay 更好。没有端口转发时，relay 也可能让设备连上，但性能会比直连差。
Linux 上如果使用 ufw 并安装了对应包，可以用：
|
|
Web GUI 默认只监听本机的 127.0.0.1:8384。如果要远程访问 GUI，可以改成 0.0.0.0:8384，但这意味着管理界面对外暴露，必须同时考虑密码、HTTPS、反向代理或 SSH 隧道。普通家庭场景下，更推荐用 SSH 隧道访问远端 GUI。
.stignore 要放在同步根目录
如果有些文件不想同步，可以在同步文件夹根目录创建 .stignore。
注意几个细节：
.stignore必须放在同步文件夹的根目录。- 规则相对于同步根目录生效。
.stignore本身不会同步到其他设备。- 文件内容应使用 UTF-8 编码。
一个简单例子：
|
|
(?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 会识别冲突。两个设备同时修改同一个文件，并且内容不同，就可能生成类似这样的冲突文件：
|
|
这比静默覆盖安全，但也意味着你要定期清理冲突文件。
容易产生冲突的场景：
- 多设备同时打开同一份 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 长期同步笔记或文档，可以按这个思路配置：
- 每类资料单独建文件夹，不要混在一个超大目录里。
- 主力电脑使用
Send & Receive。 - NAS 或备份机可以考虑
Receive Only，并开启文件版本。 - 手机端只同步必要目录，不要同步应用缓存目录。
- 用
.stignore排除缓存、临时文件、工作区状态文件。 - 局域网内优先保证
22000/TCP、22000/UDP、21027/UDP可用。 - Web GUI 尽量保持本机监听，需要远程管理时优先用 SSH 隧道。
- 重要资料不要只依赖同步，仍然需要独立备份。
在群晖 DSM 上部署 Syncthing
准备工作
先通过 SSH 登录群晖，查询用于运行 Syncthing 的用户 ID：
|
|
记下返回结果里的 uid 和 gid。常见情况是 uid 在 1026 左右，gid 为 100。后面会把它们分别填到 PUID 和 PGID。
然后在 File Station 中进入 docker 共享文件夹，新建目录：
|
|
这个目录用于保存 Syncthing 的配置文件、数据库和运行状态。后续重建容器时，只要这个目录还在，配置就能保留下来。
下载 Syncthing 镜像
打开群晖的 Container Manager，进入左侧“注册表”，搜索：
|
|
选择官方镜像 syncthing/syncthing，标签使用 latest，下载完成后进入“映像”，选中 syncthing/syncthing 并点击“运行”。
创建容器
容器名称可以直接填写：
|
|
建议勾选“启用自动重新启动”，这样群晖重启后 Syncthing 会自动恢复运行。
配置环境变量
在高级设置里的环境变量区域添加或修改：
|
|
其中 PUID 和 PGID 要替换成你前面通过 id 用户名 查到的真实值。Syncthing 后续读写共享文件夹时，会以这个用户身份访问群晖文件系统。
固定端口
为了后续访问和排错方便，建议手动固定端口映射：
| 容器端口 | 本地端口 | 协议 | 用途 |
|---|---|---|---|
8384 |
8384 |
TCP | Web 管理界面 |
22000 |
22000 |
TCP | 数据同步传输 |
22000 |
22000 |
UDP | QUIC 数据传输 |
21027 |
21027 |
UDP | 局域网发现 |
如果群晖防火墙已开启，也要放行这些端口。只在局域网内使用时，至少要确保 8384 能从你的电脑访问。
配置目录映射
目录映射分两类：一类是 Syncthing 自己的配置目录，另一类是你希望同步的群晖共享文件夹。
配置目录必须这样映射：
| 群晖宿主机路径 | 容器内装载路径 |
|---|---|
/docker/syncthing |
/var/syncthing |
然后继续添加需要同步的数据目录。例如你想同步群晖上的 /volume1/NasData，可以这样映射：
| 群晖宿主机路径 | 容器内装载路径 |
|---|---|
/volume1/NasData |
/NasData |
这里要特别注意：以后在 Syncthing 网页端添加文件夹时，填写的是容器内路径，例如：
|
|
不要填写群晖宿主机路径 /volume1/NasData。Syncthing 运行在容器里，只能看到你映射进去的容器内路径。
如果要同步多个共享文件夹，可以继续添加多条映射，例如：
|
|
启动并访问
确认环境变量、端口和目录映射无误后，点击“完成”启动容器。
然后在浏览器打开：
|
|
进入 Syncthing 管理界面后，第一件事是设置 Web 管理界面的用户名和密码。路径为：
|
|
不要让未设置密码的 Syncthing 管理界面长期暴露在局域网里。
添加同步文件夹
点击“添加文件夹”，在“文件夹路径”中填写前面设置的容器内路径，例如：
|
|
如果权限配置正确，Syncthing 就可以读写这个共享文件夹。之后再添加远端设备，并选择要共享的文件夹，就可以开始同步。
iPhone 照片同步到电脑或 NAS
先理解 iOS 上的限制
在 Android 上，Syncthing-Fork 可以通过后台服务、运行条件、电池白名单等方式长期运行。但 iOS 不允许第三方同步工具无限制后台常驻。
这意味着：
- 不能期待它像 NAS 一样 24 小时同步。
- App 进入后台后，同步时间可能很短。
- 大量照片最好主动打开 App 让它同步完。
- iCloud 优化存储可能影响原图读取。
所以，iPhone 端更适合“定期打开 App 同步照片”，而不是完全无感的后台实时同步。
第一步：安装客户端并授予权限
在 App Store 安装 Möbius Sync 后，第一次打开时要重点处理几个权限。
通知权限
建议允许通知。它可以提示同步状态、连接状态或错误信息。
本地网络权限
这个权限很重要。
iOS 会单独询问 App 是否允许访问本地网络。如果不允许，iPhone 可能无法在局域网内发现你的电脑、NAS 或 Syncthing 节点。
如果之前误点了拒绝，可以到系统设置中重新开启。
相册访问权限
如果要同步照片，必须允许访问相册。
建议选择：
|
|
如果只给有限照片访问权限，Möbius Sync 只能看到你选择的那部分照片，后续新增照片也可能不同步。
第二步：iPhone 和电脑/NAS 配对
Syncthing 的配对逻辑仍然是互相添加设备 ID。
在 iPhone 上：
- 打开 Möbius Sync。
- 进入
Settings。 - 打开
Device ID。 - 保持二维码界面。
在电脑或 NAS 上：
- 打开 Syncthing Web UI。
- 点击
添加远程设备。 - 扫描 iPhone 上的二维码，或者手动输入设备 ID。
- 给设备起名，例如
My-iPhone。 - 保存。
回到 iPhone，等待连接请求提示，然后点击 Accept。
到这里，iPhone 和电脑/NAS 已经互相信任，但还没有共享相册。
第三步：在 iPhone 上创建相册同步文件夹
iOS 不像 Android 那样直接让你选择 /DCIM/Camera 路径。Möbius Sync 对系统相册做了专门支持，配置时要选择相册类型。
在 Möbius Sync 中：
- 切换到
Folders。 - 点击右上角
+。 - 新建文件夹。
关键字段：
Folder Type：选择Camera Roll。Folder Label：填写容易识别的名字，例如iPhone_Photos。Folder ID：可以保留自动生成，也可以用稳定英文 ID。Folder Path：保持默认，让客户端关联 iOS 系统相册。
然后在 Sharing 区域勾选刚刚配对的电脑或 NAS。
第四步：iPhone 端设为 Send Only
相册同步通常是“手机发给 NAS”，不是双向编辑。
因此，在 iPhone 端把文件夹类型设为：
|
|
这样 iPhone 负责把照片发送出去，不接收电脑或 NAS 的反向修改。
这个设置可以降低误操作风险。比如你在电脑端整理备份目录时，不希望这些改动影响 iPhone 相册。
但仍然要记住：Syncthing 是同步工具，不是完整备份系统。真正的长期照片安全，还需要 NAS 端快照、文件版本或独立备份。
第五步：在电脑或 NAS 端接收照片
iPhone 端保存后，电脑或 NAS 的 Syncthing Web UI 会出现提示：
|
|
点击添加。
设置保存路径。
Windows 可以类似：
|
|
Linux 或 NAS 可以类似：
|
|
如果 Syncthing 跑在 Docker 中，要填写容器内路径。例如宿主机挂载：
|
|
Web UI 中应填写：
|
|
接收端建议设为 Receive Only
在电脑或 NAS 端，也建议把这个文件夹类型设为：
|
|
这样接收端只接收 iPhone 发来的照片，不把本地变化同步回 iPhone。
这是第二层保险：
- iPhone 端
Send Only - NAS 端
Receive Only
两边都按单向备份思路配置，更符合照片归档场景。
iOS 后台同步的现实限制
iOS 对后台运行限制很严格。即使配置正确，也不要期待 Möbius Sync 一直在后台默默跑。
常见情况是：
- App 打开时同步速度正常。
- 切到后台后还能同步一小段时间。
- 过一会儿系统会暂停或限制它。
- 位置变化、系统调度或短暂后台窗口可能再次唤醒。
最佳实践很朴素：
- 拍了大量照片后，主动打开 Möbius Sync。
- 让手机保持亮屏或不要太快锁屏。
- 等待它把新照片同步完。
- 再关闭 App 或锁屏。
如果你习惯每隔几天做一次相册备份，这个方式比较可靠。
避免 iCloud 优化存储影响同步
如果 iPhone 开启了：
|
|
系统可能只在本地保留缩略图，原图留在 iCloud。第三方同步客户端读取照片时，可能拿不到完整原图，导致同步失败、跳过或需要等待系统下载。
更适合同步备份的设置是：
|
|
路径通常在：
|
|
如果手机空间不够，必须开启优化存储，那么同步前可能需要先在系统相册里打开相关照片，让 iPhone 把原图从 iCloud 下载回来，再启动 Möbius Sync 同步。
大量照片首次同步建议
第一次同步 iPhone 相册时，可能有几千张甚至几万张照片。建议不要急着一次做完。
可以这样处理：
- 先同步少量照片测试。
- 确认 NAS 路径正确。
- 确认文件夹类型是 Send Only / Receive Only。
- 确认接收端不会反向影响 iPhone。
- 再开始完整同步。
首次同步时最好：
- iPhone 接入电源。
- 保持 Wi-Fi 稳定。
- 打开 Möbius Sync 前台运行。
- NAS 或电脑保持在线。
照片数量很大时，同步时间可能比较长，这是正常的。
推荐配置
一个比较稳的 iPhone 照片同步方案：
- iPhone 安装 Möbius Sync。
- 允许通知、本地网络和完整相册访问。
- iPhone 与 NAS 互加设备 ID。
- 在 iPhone 新建
Camera Roll文件夹。 - 文件夹标签设为
iPhone_Photos。 - iPhone 端文件夹类型设为
Send Only。 - NAS 端接收路径设为
/volume1/photos/iphone。 - NAS 端文件夹类型设为
Receive Only。 - NAS 端开启文件版本或快照。
- 每隔几天主动打开 Möbius Sync 完成同步。
如果你非常依赖自动后台照片备份，iOS 会比 Android 麻烦一些。iOS 的限制决定了第三方同步工具很难做到完全无感后台常驻。
多文件夹治理与版本控制
Folder ID 比文件夹标签更重要
在 Syncthing 中，真正识别一个同步文件夹的是 Folder ID，不是你看到的标签名。
标签只是显示名称，可以在不同设备上不一样。Folder ID 才是判断“这些设备上的文件夹属于同一个同步组”的关键。
所以，在第一台设备创建文件夹时，建议手动指定规范 ID。
例如：
|
|
不要使用随手生成的随机 ID，也不要只写 test、sync、new-folder 这类无法长期维护的名字。
命名规则可以简单一些：
- 双向同步：
notes-main、work-docs - 手机备份：
backup-pixel-photos、backup-iphone-photos - 资料分发：
media-ebooks、media-music - 代码目录：
code-projects
以后在其他设备接收共享时，只要看到 Folder ID，就能判断它是什么用途。
中心节点路径要规范
在 NAS 或中心电脑上，建议创建一个统一的 Syncthing 根目录。
例如：
|
|
不要把同步目录散落在系统各处。散落的目录短期方便，长期一定难维护。
推荐原则：
- 所有 Syncthing 管理的目录放在统一根目录下。
- 手机备份、工作文档、媒体资料分区存放。
- 文件夹名体现用途，不体现临时设备状态。
- 不把系统目录、下载缓存目录直接作为长期同步目录。
如果 Syncthing 跑在 Docker 中，还要注意容器内路径和宿主机路径的对应关系。
例如宿主机目录：
|
|
映射到容器内：
|
|
Web UI 里填写的是容器内路径，不是宿主机路径。
区分备份和双向同步
多文件夹管理里，最重要的一件事是：不要所有目录都用 Send & Receive。
不同目录的数据方向不一样。
手机照片备份
手机端：
|
|
NAS 端：
|
|
这样手机负责发送照片，NAS 负责接收保存。手机清理空间、NAS 整理目录时，都不容易互相影响。
多端文档和笔记
电脑端：
|
|
NAS 端：
|
|
手机端是否加入双向同步，要看你是否真的在手机上编辑这些文件。如果手机只查看资料，可以考虑 Receive Only。
资料分发
NAS 端：
|
|
其他设备：
|
|
适合电子书、安装包、参考资料这类中心分发目录。
备份目录
主设备：
|
|
备份机：
|
|
再配合备份机端版本控制或快照。
NAS 上开启文件版本控制
多设备同步最怕误删和误覆盖。
例如：
- 某台电脑误删了工作文档。
- 手机清理工具删了相册目录。
- 两台设备同时改了同一份笔记。
- 某个同步规则写错，把空目录同步过去。
因此，中心节点最好开启文件版本控制。
在 NAS 的 Syncthing Web UI 中：
- 打开对应文件夹设置。
- 进入文件版本控制。
- 选择合适的版本策略。
常用选择是 Staggered File Versioning，也就是阶段版本控制。它会按时间间隔保留历史版本，越旧保留得越稀疏。
也可以用更简单的策略：
- Trash Can File Versioning：类似回收站。
- Simple File Versioning：保留固定数量版本。
- Staggered File Versioning：按时间阶段保留。
如果不知道选什么，普通家庭 NAS 可以先从 Trash Can 或 Staggered 开始。
版本控制不是完整备份，但它是多设备同步里的后悔药。
多文件夹命名示例
可以建立一套固定命名方式。
手机照片：
|
|
iPhone 照片：
|
|
主笔记库：
|
|
工作文档：
|
|
电子书：
|
|
只要 ID、标签、路径都有规律，多设备之后也不会失控。
推荐整体方案
如果你已经有 Docker 版 Syncthing 跑在 NAS 上，可以这样设计：
- NAS 作为中心节点。
- NAS 设为引入者。
- 所有设备只和 NAS 配对。
- 所有同步目录放在
/volume1/Syncthing/下面。 - 手机照片目录使用手机
Send Only、NASReceive Only。 - 工作文档和笔记使用
Send & Receive。 - 资料分发目录使用 NAS
Send Only、其他设备Receive Only。 - NAS 上对重要文件夹开启版本控制。
- 代码和缓存目录配置忽略规则。
- NAS 本身再做快照或异地备份。
这套结构建立起来后，再增加新设备或新文件夹，只需要按规则放进去，不需要每次重新思考同步关系。
多设备拓扑与配对
先理解“对等”和“伪服务器”
Syncthing 里的每台设备都有自己的 device ID。只要两台设备互相添加对方 ID，并且共享同一个文件夹，它们就能同步。
所以，Syncthing 本身没有“服务器端必须保存所有数据”这个概念。你看到的“服务器”，往往只是人为指定的一台常开设备。
比如：
- NAS 长期开机、空间大，适合作为中心节点。
- 手机和笔记本经常离线，适合作为边缘设备。
- 台式机性能强，但不一定 24 小时开机，可以作为普通同步节点。
这个“中心节点”不是协议上的服务器，而是你在拓扑设计中让它承担管理和中转角色。
模式一：纯对等 Mesh 网络
纯对等模式下，每台设备都和其他所有设备配对。
例如你有四台设备：
- NAS
- 台式机
- 笔记本
- 手机
那么每台设备都要和另外三台设备建立连接。这样任何两台在线设备之间都可以直接同步。
优点：
- 传输路径更直接。
- 某台设备离线时，其他在线设备仍然可以互相同步。
- 不依赖某一个中心节点。
缺点：
- 设备越多，配对关系越复杂。
- 新增设备时，需要在多台旧设备上确认和配置。
- 文件夹共享关系容易散。
设备数量少时，纯对等模式很舒服。比如只有一台电脑和一台手机，或者两台电脑互相同步笔记，就不需要想太复杂。
但当设备数量变成五六台以上，手动维护全连接关系会越来越麻烦。
模式二：以 NAS 为中心的星型拓扑
星型模式更适合家庭和个人生产力场景。
做法是：选一台长期开机、空间足够、网络稳定的设备作为中心节点，例如：
- NAS
- 群晖
- 软路由
- 迷你主机
- 家用 Linux 服务器
然后其他设备只和它配对：
|
|
手机不需要直接配对笔记本，笔记本也不需要直接配对台式机。它们都通过 NAS 间接同步数据。
优点：
- 管理简单。
- 新增设备只需要和 NAS 配对。
- NAS 可以承担版本保留和备份缓冲。
- 适合 24 小时在线同步。
缺点：
- NAS 离线时，其他设备之间不一定能继续同步。
- 如果所有流量都经过 NAS，NAS 的网络和磁盘性能会影响体验。
- 中心节点权限要管理好。
如果你已经有 NAS 或常开小主机，优先推荐星型拓扑。它保留了 Syncthing 的 P2P 能力，又让日常管理更接近“中心化同步”。
多设备配置的基本顺序
不管用哪种拓扑，Syncthing 的配置顺序都是：
- 先配对设备。
- 再共享文件夹。
- 最后在接收端确认路径。
不要反过来一开始就到处建文件夹。先把设备关系理清楚，后面才不容易乱。
第一步：设备互联
假设要连接设备 A 和设备 B。
设备 A 可以是手机，设备 B 可以是 NAS 或电脑。
在设备 A 上：
- 打开 Syncthing Web UI。
- 点击右上角
操作。 - 选择
显示 ID。 - 复制设备 ID，或者显示二维码。
在设备 B 上：
- 打开 Syncthing Web UI。
- 点击
添加远程设备。 - 填入设备 A 的 ID。
- 给设备起一个容易识别的名称，例如
My-Phone。 - 保存。
然后回到设备 A。它通常会弹出提示：设备 B 想要连接。点击接受。
到这一步，两台设备已经建立了对等关系，但还没有开始同步任何文件夹。
第二步：创建并共享文件夹
在设备 A 上点击 添加文件夹。
常用字段：
- 文件夹标签：给自己看的名字，例如
Notes。 - 文件夹 ID：跨设备识别用，建议用稳定英文，例如
notes。 - 文件夹路径：这台设备上的真实路径。
然后切换到 共享 标签页，勾选刚刚配对成功的设备 B。
保存后，设备 A 会把这个文件夹共享邀请发给设备 B。
第三步：接收共享
打开设备 B 的 Web UI，等待几秒钟，通常会看到提示：
|
|
点击添加，然后在设备 B 上指定本地存储路径。
例如：
|
|
或者 Docker 部署场景下的容器内路径：
|
|
保存后，同步正式开始。
这里要注意：不同设备上的路径可以不一样。Syncthing 通过文件夹 ID 识别同步关系，不要求每台设备使用相同的本地路径。
星型拓扑怎么配置
如果你采用 NAS 中心模式，建议这样做：
- 先在 NAS 上部署 Syncthing。
- 所有手机、电脑、服务器都只和 NAS 配对。
- 在 NAS 上创建或接收主要同步文件夹。
- 每台新设备只添加 NAS 的 device ID。
- 需要同步哪个文件夹，就在 NAS 和对应设备之间共享。
例如：
|
|
这样结构非常清楚。你可以把 NAS 当作同步关系的控制面。
引入者是什么
Syncthing 有一个很实用的功能：Introducer，中文界面里通常叫“引入者”。
它适合多设备场景。
假设你把 NAS 设置为引入者。之后新设备只要和 NAS 配对，NAS 就可以把它知道的其他设备介绍给新设备，也可以帮助同步已有的共享关系。
这样做可以减少重复点击和重复配对。
适合：
- 家里有多台电脑和手机。
- NAS 作为长期中心节点。
- 经常新增设备。
- 希望减少手工维护设备关系。
但也要注意，引入者会扩大自动建立关系的范围。不要把不完全信任的设备设为引入者，也不要在不清楚拓扑的情况下随手勾选。
更稳妥的做法是：
- 只把 NAS 或主服务器设为引入者。
- 普通手机、笔记本不要设为引入者。
- 新设备加入后，检查它被自动添加了哪些设备和文件夹。
不同目录可以用不同拓扑
Syncthing 的拓扑不一定全站统一。你可以按文件夹设计。
例如：
notes：电脑、笔记本、手机、NAS 都使用 Send & Receive。photos：手机发送，NAS 接收并保留版本。downloads：NAS 和台式机同步，手机不参与。backup：主电脑 Send Only，NAS Receive Only。
不要把所有目录都套进一种规则。多设备同步真正重要的是数据方向，而不是设备数量。
冲突和误删要提前想
多设备同步最常见的问题不是配置失败，而是同步成功之后发生误删或冲突。
容易出问题的场景：
- 两台设备同时编辑同一个文件。
- 手机端应用自动清理目录。
- 一台设备路径填错，创建了空目录并同步过去。
- 把缓存、临时文件、工作区状态文件一起同步。
- NAS 端没有开启版本保留。
建议：
- 重要目录在 NAS 上开启文件版本。
- 使用
.stignore排除缓存和临时文件。 - 新文件夹第一次同步前，先用少量测试文件验证。
- 不确定删除策略时，不要把所有设备都设为 Send & Receive。
推荐配置
如果你有 NAS 或常开服务器，推荐直接使用星型拓扑：
- NAS 作为中心节点。
- NAS 和所有设备配对。
- 普通设备只和 NAS 配对。
- NAS 可以设为引入者。
- 不同文件夹按用途选择 Send & Receive、Send Only 或 Receive Only。
- 重要文件夹在 NAS 上开启文件版本。
- 新设备加入后，先共享一个测试文件夹确认路径和权限。
如果你只有两三台设备，而且都经常在线，可以用纯对等模式。它更直接，速度也可能更好。
适合和不适合
Syncthing 适合：
- 你希望数据主要留在自己的设备上。
- 你愿意理解设备配对、同步目录和冲突处理。
- 你有 NAS、家用服务器或多台个人设备。
- 你想同步 Markdown、照片中转、脚本、轻量文档。
Syncthing 不太适合：
- 需要多人在线协作编辑。
- 需要网页端文件预览和分享链接。
- 需要细粒度团队权限。
- 不想处理任何网络、防火墙和冲突问题。
它更像一个可靠的“设备间同步层”，而不是完整的云盘产品。用得好，Syncthing 可以把 NAS、电脑、手机连成一个可控的数据网络；用得太随意，也可能因为冲突、误删、忽略规则和网络配置变成维护负担。