Syncthing on KnightLi的博客

Syncthing 多设备多文件夹怎么管理？拓扑、命名和版本控制

Sun, 31 May 2026 12:23:55 +0800

Syncthing 系列目录

Syncthing 设备一多，文件夹一多，如果不提前规划，很快就会乱。

典型情况是：手机、平板、笔记本、台式机、NAS 都在同步；文件夹里又有照片、工作文档、代码项目、微信备份、电子书。每个设备都能改，每个目录都可能共享，最后你很难判断“这个文件到底从哪里来，又会同步到哪里去”。

要把 Syncthing 用稳，核心不是多装几个客户端，而是建立一套管理规则：

拓扑上用星型结构。
文件夹上统一 ID 和路径。
设备关系上使用引入者。
数据方向上区分备份和双向同步。
中心节点上开启版本控制。
临时文件用忽略规则过滤。

拓扑：放弃全连接，优先星型

Syncthing 是 P2P 对等架构，但不代表所有设备都要两两配对。

如果 5 台设备互相全连接，需要维护 10 组设备关系。新增一个文件夹时，还要在多台设备上接收、设置路径、确认共享。设备越多，管理成本越高。

更推荐的方式是星型拓扑。

选一台长期在线、空间大、网络稳定的设备作为中心节点：

NAS
群晖
软路由
迷你主机
24 小时开机的电脑

其他设备只和中心节点配对：

手机 ----\
平板 -----\
笔记本 ---- NAS
台式机 ---/

手机不直接加笔记本，笔记本也不直接加台式机。手机要把照片同步给电脑，先同步到 NAS，再由 NAS 同步给电脑。

这样做的好处是：

新设备只需要和 NAS 配对。
文件夹关系集中在 NAS 上管理。
NAS 可以统一做版本保留。
设备离线时，NAS 仍然能作为缓冲点。

缺点是 NAS 更重要了。它应该稳定运行，并且需要单独备份。

Folder ID 比文件夹标签更重要

在 Syncthing 中，真正识别一个同步文件夹的是 Folder ID，不是你看到的标签名。

标签只是显示名称，可以在不同设备上不一样。Folder ID 才是判断“这些设备上的文件夹属于同一个同步组”的关键。

所以，在第一台设备创建文件夹时，建议手动指定规范 ID。

例如：

notes-main
work-docs
backup-pixel-photos
backup-iphone-photos
media-ebooks
code-projects

不要使用随手生成的随机 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 根目录。

例如：

/volume1/Syncthing/
├── Phone_Backup/
│   ├── iPhone15_DCIM/
│   └── Pixel7_DCIM/
├── Work/
│   ├── Office_Docs/
│   └── Coding_Projects/
├── Notes/
│   └── Main_Notes/
└── Media/
    └── eBooks/

不要把同步目录散落在系统各处。散落的目录短期方便，长期一定难维护。

推荐原则：

所有 Syncthing 管理的目录放在统一根目录下。
手机备份、工作文档、媒体资料分区存放。
文件夹名体现用途，不体现临时设备状态。
不把系统目录、下载缓存目录直接作为长期同步目录。

如果 Syncthing 跑在 Docker 中，还要注意容器内路径和宿主机路径的对应关系。

例如宿主机目录：

`1`	`/volume1/Syncthing/Phone_Backup/iPhone15_DCIM`

映射到容器内：

`1`	`/var/syncthing/Phone_Backup/iPhone15_DCIM`

Web UI 里填写的是容器内路径，不是宿主机路径。

引入者：减少多设备配对成本

Syncthing 的 Introducer，中文界面通常叫“引入者”。

它适合星型拓扑。

做法是：把 NAS 设为引入者。之后新设备只要和 NAS 配对，NAS 就可以把已知设备和共享关系介绍给新设备，减少你在各个设备之间重复扫码、重复添加的工作。

适合：

家里有多台电脑和手机。
NAS 是长期中心节点。
经常新增设备。
希望减少设备配对操作。

但不要乱用。

建议：

只把 NAS 或主服务器设为引入者。
普通手机、平板、临时电脑不要设为引入者。
新设备加入后，检查它被自动添加了哪些设备和文件夹。
不信任的设备不要进入引入者管理范围。

引入者能提高效率，也会扩大自动关联范围。它适合有清晰中心节点的网络，不适合混乱的临时设备环境。

区分备份和双向同步

多文件夹管理里，最重要的一件事是：不要所有目录都用 Send & Receive。

不同目录的数据方向不一样。

手机照片备份

手机端：

`1`	`Send Only`

NAS 端：

`1`	`Receive Only`

这样手机负责发送照片，NAS 负责接收保存。手机清理空间、NAS 整理目录时，都不容易互相影响。

多端文档和笔记

电脑端：

`1`	`Send & Receive`

NAS 端：

`1`	`Send & Receive`

手机端是否加入双向同步，要看你是否真的在手机上编辑这些文件。如果手机只查看资料，可以考虑 Receive Only。

资料分发

NAS 端：

`1`	`Send Only`

其他设备：

`1`	`Receive Only`

适合电子书、安装包、参考资料这类中心分发目录。

备份目录

主设备：

`1`	`Send Only`

备份机：

`1`	`Receive Only`

再配合备份机端版本控制或快照。

NAS 上开启文件版本控制

多设备同步最怕误删和误覆盖。

例如：

某台电脑误删了工作文档。
手机清理工具删了相册目录。
两台设备同时改了同一份笔记。
某个同步规则写错，把空目录同步过去。

因此，中心节点最好开启文件版本控制。

在 NAS 的 Syncthing Web UI 中：

打开对应文件夹设置。
进入文件版本控制。
选择合适的版本策略。

常用选择是 Staggered File Versioning，也就是阶段版本控制。它会按时间间隔保留历史版本，越旧保留得越稀疏。

也可以用更简单的策略：

Trash Can File Versioning：类似回收站。
Simple File Versioning：保留固定数量版本。
Staggered File Versioning：按时间阶段保留。

如果不知道选什么，普通家庭 NAS 可以先从 Trash Can 或 Staggered 开始。

版本控制不是完整备份，但它是多设备同步里的后悔药。

用忽略规则过滤临时文件

多设备同步代码项目、文档目录或聊天备份时，临时文件和缓存很容易制造麻烦。

常见问题：

占用大量带宽。
产生无意义冲突。
不同系统生成不同缓存文件。
删除目录时被忽略文件阻挡。

可以在文件夹设置的 Ignore Patterns 中添加规则。

通用临时文件：

1
2
3

(?d).DS_Store
(?d)Thumbs.db
(?d)*~

Node / Python / Java 项目：

(?d)node_modules/
(?d)__pycache__/
(?d).pytest_cache/
(?d)target/

如果代码项目本身已经由 Git 管理，通常不建议用 Syncthing 同步 .git 目录。可以忽略：

`1`	`(?d).git/`

(?d) 的意思是：如果整个目录准备被删除，Syncthing 可以删除这些本地生成的忽略文件，不会因为残留缓存而阻止目录删除。

忽略规则不要一次写太复杂。先覆盖最明显的缓存和临时文件，再根据实际冲突慢慢调整。

多文件夹命名示例

可以建立一套固定命名方式。

手机照片：

1
2
3

Folder ID: backup-pixel-photos
Label: Pixel Photos
NAS Path: /volume1/Syncthing/Phone_Backup/Pixel7_DCIM

iPhone 照片：

1
2
3

Folder ID: backup-iphone-photos
Label: iPhone Photos
NAS Path: /volume1/Syncthing/Phone_Backup/iPhone15_DCIM

主笔记库：

1
2
3

Folder ID: notes-main
Label: Main Notes
NAS Path: /volume1/Syncthing/Notes/Main_Notes

工作文档：

1
2
3

Folder ID: work-docs
Label: Work Docs
NAS Path: /volume1/Syncthing/Work/Office_Docs

电子书：

1
2
3

Folder ID: media-ebooks
Label: eBooks
NAS Path: /volume1/Syncthing/Media/eBooks

只要 ID、标签、路径都有规律，多设备之后也不会失控。

总结

Syncthing 的自由度很高，但自由度越高，越需要规则。

多设备、多文件夹场景下，不建议做全连接网状同步。更稳的方式是让 NAS 或常开电脑做中心节点，统一 Folder ID、统一路径、统一版本控制，再用文件夹类型区分备份、双向同步和资料分发。

这样既保留了 Syncthing 的 P2P 能力，又把日常管理收束到一台中心设备上。设备再多，文件夹再多，也不会变成一团乱线。

Syncthing 如何同步 iPhone 照片到电脑或 NAS

Sun, 31 May 2026 12:21:54 +0800

Syncthing 系列目录

iPhone 上使用 Syncthing 同步照片，和 Android 很不一样。

原因很简单：iOS 系统更封闭，Syncthing 官方没有提供正式 iOS 客户端。想在 iPhone 上使用 Syncthing 协议，通常需要第三方兼容客户端。

常见选择有两个：

Möbius Sync：比较主流，体验接近原生 App，部分能力可能需要付费解锁，具体以 App Store 当前说明为准。
FSync：免费开源的 Syncthing iOS 客户端。

如果目标是把 iPhone 相册同步到电脑或 NAS，Möbius Sync 是更常见的选择。下面以它为例整理配置流程。

先理解 iOS 上的限制

在 Android 上，Syncthing-Fork 可以通过后台服务、运行条件、电池白名单等方式长期运行。但 iOS 不允许第三方同步工具无限制后台常驻。

这意味着：

不能期待它像 NAS 一样 24 小时同步。
App 进入后台后，同步时间可能很短。
大量照片最好主动打开 App 让它同步完。
iCloud 优化存储可能影响原图读取。

所以，iPhone 端更适合“定期打开 App 同步照片”，而不是完全无感的后台实时同步。

第一步：安装客户端并授予权限

在 App Store 安装 Möbius Sync 后，第一次打开时要重点处理几个权限。

通知权限

建议允许通知。它可以提示同步状态、连接状态或错误信息。

本地网络权限

这个权限很重要。

iOS 会单独询问 App 是否允许访问本地网络。如果不允许，iPhone 可能无法在局域网内发现你的电脑、NAS 或 Syncthing 节点。

如果之前误点了拒绝，可以到系统设置中重新开启。

相册访问权限

如果要同步照片，必须允许访问相册。

建议选择：

`1`	`Full Access to Photos`

如果只给有限照片访问权限，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 端把文件夹类型设为：

`1`	`Send Only`

这样 iPhone 负责把照片发送出去，不接收电脑或 NAS 的反向修改。

这个设置可以降低误操作风险。比如你在电脑端整理备份目录时，不希望这些改动影响 iPhone 相册。

但仍然要记住：Syncthing 是同步工具，不是完整备份系统。真正的长期照片安全，还需要 NAS 端快照、文件版本或独立备份。

第五步：在电脑或 NAS 端接收照片

iPhone 端保存后，电脑或 NAS 的 Syncthing Web UI 会出现提示：

`1`	`设备 My-iPhone 想共享文件夹 iPhone_Photos`

点击添加。

设置保存路径。

Windows 可以类似：

`1`	`D:\Backups\iPhone_Photos`

Linux 或 NAS 可以类似：

`1`	`/volume1/photos/iphone`

如果 Syncthing 跑在 Docker 中，要填写容器内路径。例如宿主机挂载：

`1`	`- /volume1/photos:/var/syncthing/photos`

Web UI 中应填写：

`1`	`/var/syncthing/photos/iphone`

接收端建议设为 Receive Only

在电脑或 NAS 端，也建议把这个文件夹类型设为：

`1`	`Receive Only`

这样接收端只接收 iPhone 发来的照片，不把本地变化同步回 iPhone。

这是第二层保险：

iPhone 端 Send Only
NAS 端 Receive Only

两边都按单向备份思路配置，更符合照片归档场景。

iOS 后台同步的现实限制

iOS 对后台运行限制很严格。即使配置正确，也不要期待 Möbius Sync 一直在后台默默跑。

常见情况是：

App 打开时同步速度正常。
切到后台后还能同步一小段时间。
过一会儿系统会暂停或限制它。
位置变化、系统调度或短暂后台窗口可能再次唤醒。

最佳实践很朴素：

拍了大量照片后，主动打开 Möbius Sync。
让手机保持亮屏或不要太快锁屏。
等待它把新照片同步完。
再关闭 App 或锁屏。

如果你习惯每隔几天做一次相册备份，这个方式比较可靠。

避免 iCloud 优化存储影响同步

如果 iPhone 开启了：

`1`	`优化 iPhone 存储`

系统可能只在本地保留缩略图，原图留在 iCloud。第三方同步客户端读取照片时，可能拿不到完整原图，导致同步失败、跳过或需要等待系统下载。

更适合同步备份的设置是：

下载并保留原片

路径通常在：

`1`	`设置 -> Apple ID -> iCloud -> 照片`

如果手机空间不够，必须开启优化存储，那么同步前可能需要先在系统相册里打开相关照片，让 iPhone 把原图从 iCloud 下载回来，再启动 Möbius Sync 同步。

大量照片首次同步建议

第一次同步 iPhone 相册时，可能有几千张甚至几万张照片。建议不要急着一次做完。

可以这样处理：

先同步少量照片测试。
确认 NAS 路径正确。
确认文件夹类型是 Send Only / Receive Only。
确认接收端不会反向影响 iPhone。
再开始完整同步。

首次同步时最好：

iPhone 接入电源。
保持 Wi-Fi 稳定。
打开 Möbius Sync 前台运行。
NAS 或电脑保持在线。

照片数量很大时，同步时间可能比较长，这是正常的。

总结

iPhone 可以通过 Möbius Sync 或 FSync 接入 Syncthing 生态，把照片同步到电脑或 NAS。

但 iOS 的关键差异是后台限制和相册权限。配置时要允许本地网络和完整相册访问，文件夹类型按单向备份设计：iPhone Send Only，NAS Receive Only。如果开启了 iCloud 优化存储，还要注意本地是否真的有原图。

用它做照片归档时，最稳的方式是定期主动打开客户端同步，再让 NAS 负责版本保留、快照和长期备份。

Android 上怎么用 Syncthing？Syncthing-Fork 配置与照片备份

Sun, 31 May 2026 12:17:19 +0800

Syncthing 系列目录

Android 上使用 Syncthing，常见选择有两个：

Syncthing 官方原版 Android 客户端。
Syncthing-Fork 社区增强版。

如果只是简单体验，两者都能用。但如果你希望长期同步手机照片、笔记或文档，更推荐 Syncthing-Fork。它对 Android 的后台、电池和网络条件适配更细，支持仅 Wi-Fi 同步、指定 Wi-Fi 同步、仅充电时运行等功能，更适合手机端长期使用。

这篇把 Android 端常规配置和照片备份合在一起讲。照片备份是 Syncthing 在手机上的经典用法，但它不应该按普通双向同步来配置。

为什么更推荐 Syncthing-Fork

Android 系统会主动限制后台应用。手机熄屏后，系统可能暂停网络、冻结进程，甚至直接杀掉后台服务。普通同步工具如果没有处理好这些限制，就容易出现“打开 App 才同步，锁屏后就断”的情况。

Syncthing-Fork 的优势主要在手机使用体验：

可以设置运行条件。
可以只在 Wi-Fi 下同步。
可以只在指定 Wi-Fi 下同步。
可以只在充电时同步。
对 Android 后台限制的适配更实用。

这不代表官方原版不能用，而是 Syncthing-Fork 更像“为手机长期同步场景调过的版本”。

安装来源

Syncthing-Fork 常见安装来源包括：

Google Play
F-Droid
GitHub Releases

优先选择你平时信任的渠道。安装完成后，先不要急着添加设备，先把权限和后台运行条件处理好。

第一步：授予必要权限

首次打开 Syncthing-Fork 时，重点看两个权限。

存储权限

Android 端同步文件，必须让应用能读写目标目录。

较新的 Android 版本通常会提示“所有文件访问权限”或类似权限。如果不给权限，Syncthing-Fork 可能只能看到很有限的目录，无法读取相册、文档或你指定的同步文件夹。

建议：

给 Syncthing-Fork 授予必要的文件访问权限。
同步目录尽量放在内置存储中的普通目录。
不要优先选择系统保护目录。

例如可以使用：

1
2
3

/storage/emulated/0/SyncData
/storage/emulated/0/SyncData/Notes
/storage/emulated/0/SyncData/Photos

如果要同步相机照片，常见路径是：

`1`	`/storage/emulated/0/DCIM/Camera`

电池优化白名单

这是 Android 端最关键的一步。

如果 Syncthing-Fork 没有被排除出电池优化，手机锁屏后系统可能杀掉同步进程。表现就是：你以为它在后台同步，实际上只有打开 App 时才动一下。

建议在系统设置中把 Syncthing-Fork 加入电池优化白名单。不同品牌手机名称不一样，可能叫：

不优化
允许后台运行
允许自启动
锁定后台
后台高耗电允许

国产 Android 系统通常还会额外限制后台和自启动。如果同步不稳定，要同时检查系统电池管理和应用自启动设置。

第二步：和 NAS 或电脑配对

Syncthing 的设备配对逻辑是互相添加 device ID。

假设手机是设备 A，NAS 或电脑是设备 B。

在手机端：

打开 Syncthing-Fork。
进入菜单。
选择显示设备 ID。
你会看到二维码和一长串设备 ID。

在 NAS 或电脑端：

打开 Syncthing Web UI。
点击 添加远程设备。
扫描手机二维码，或者手动输入手机设备 ID。
给手机起一个清楚的名字，例如 Android-Phone 或 Pixel-Phone。
保存。

回到手机端，通常会看到连接请求提示。点击接受。

到这里，两台设备只是建立了信任关系，还没有同步任何文件夹。

第三步：接收 NAS 或电脑共享的文件夹

如果电脑或 NAS 已经把某个文件夹共享给手机，手机端会收到提示。

例如：

`1`	`设备 NAS 想共享文件夹 Notes`

点击添加后，在手机上指定本地路径。例如：

`1`	`/storage/emulated/0/SyncData/Notes`

保存后，手机会开始从 NAS 或电脑下载文件。

这个路径建议提前手动建好，避免 Syncthing-Fork 自动创建到你不熟悉的位置。

如果你同步的是 Markdown 笔记，要注意是否需要同步应用配置目录。以 Obsidian 为例，.obsidian 目录里有工作区状态、插件配置和缓存。多端插件差异很大时，建议先只同步正文和附件，避免把手机端工作区状态同步回电脑。

第四步：把手机照片备份到电脑或 NAS

手机端最常见的需求是把相册备份到 NAS 或电脑。

照片备份和普通文件同步不一样。大多数人想要的是“手机拍照后自动传到 NAS”，而不是“手机删了照片，NAS 上也跟着删”。所以这类场景更接近单向备份，需要特别注意文件夹类型。

推荐组合是：

手机端：Send Only
电脑或 NAS 端：Receive Only

这样手机负责发送照片，NAS 负责接收和保存。再配合 NAS 端文件版本或快照，误删风险会小很多。

手机端添加相册文件夹

在 Syncthing-Fork 的文件夹页面中：

点击右上角 +。
新建文件夹。
文件夹标签填写容易识别的名字，例如 Pixel_Photos 或 Huawei_DCIM。
文件夹路径选择手机相册目录。
共享设备勾选你的电脑或 NAS。

Android 相机照片通常在：

`1`	`/storage/emulated/0/DCIM/Camera`

如果你还想同步截图、微信图片或其他 App 保存的图片，通常需要单独添加文件夹。例如：

1
2

/storage/emulated/0/Pictures/Screenshots
/storage/emulated/0/Pictures/WeiXin

不同手机和应用路径可能不同，建议先用系统文件管理器确认。

手机端改为 Send Only

在手机端文件夹设置中，找到文件夹类型，把默认的：

`1`	`Send & Receive`

改成：

`1`	`Send Only`

这样手机只负责把照片发出去。

这个设置的意义是：手机是照片来源。你在手机上拍了新照片，Syncthing 会把它传给 NAS；但 NAS 端的变化不会反向写回手机。

不过要注意，Syncthing 仍然是同步工具，不是完整备份系统。要想更稳，还需要在 NAS 端开启文件版本、快照或单独备份。

接收端设置保存路径

手机端保存后，电脑或 NAS 的 Syncthing Web UI 会弹出提示：

`1`	`设备 Pixel-Phone 想共享文件夹 Pixel_Photos`

点击添加。

在接收端设置本地保存路径。

Windows 可以类似：

`1`	`D:\Backups\Phone_Photos`

Linux 或 NAS 可以类似：

`1`	`/volume1/photos/phone`

Docker 部署时，要填写容器内路径。例如宿主机映射：

`1`	`- /volume1/photos:/var/syncthing/photos`

那么 Web UI 里应填写：

`1`	`/var/syncthing/photos/phone`

接收端改为 Receive Only

在电脑或 NAS 端的文件夹高级设置里，把文件夹类型设为：

`1`	`Receive Only`

这样接收端只接收手机发来的照片，不把本地变化发回手机。

这是一层保护：即使你在电脑或 NAS 上整理照片、移动文件、误删文件，也不会直接反向影响手机里的原图。

更稳的做法是：NAS 端再开启文件版本或快照。因为 Receive Only 可以避免反向影响手机，但不能替代 NAS 自己的历史版本能力。

第一次同步前先小规模测试

不要一开始就同步几万张照片。

建议先这样测试：

在手机相册里临时放 3-5 张照片。
确认电脑或 NAS 能接收到。
在手机上新增一张照片，看是否自动同步。
在手机上删除一张测试照片，观察 NAS 端行为。
确认结果符合预期后，再放开完整相册。

不同文件夹类型和删除动作的组合很容易产生误解，先用小样本验证能避免大规模整理成本。

运行条件：防止偷跑流量

Syncthing-Fork 的运行条件很适合 Android。

建议进入设置里的运行条件，至少开启：

`1`	`仅在 Wi-Fi 连接时运行`

这样可以避免在 5G 或 4G 网络下自动同步大文件。

如果你只想在家里同步，可以进一步设置指定 Wi-Fi SSID。例如只允许在家里的 Wi-Fi 下运行，不在公司、酒店或朋友家 Wi-Fi 下同步。

适合这样设置的场景：

手机照片很多，不想消耗移动流量。
NAS 只在家中局域网可访问。
不希望外部网络下进行大规模同步。

充电时同步：更省电的工作流

如果你不需要实时同步，可以开启：

仅在充电时运行

这个设置对照片备份特别实用。

一个稳定工作流是：

白天正常拍照、写笔记。
Syncthing-Fork 不持续后台运行，减少耗电。
晚上回家连接家庭 Wi-Fi。
插上充电器。
Syncthing-Fork 自动运行，把当天照片和文件同步到 NAS。

这比全天候后台同步更省电，也更符合手机使用习惯。

如果你同步的是随时要用的笔记，可以不要开启“仅充电时运行”，而是只限制 Wi-Fi。具体取决于你对实时性的要求。

Android 11 之后的存储限制

Android 11 之后，系统对存储访问限制更严格。某些目录可能无法稳定读写，尤其是：

1
2

Android/data
Android/obb

SD 卡目录也可能受限制，具体取决于手机厂商、Android 版本和文件选择器授权方式。

建议：

尽量在内置存储根目录下建立专用同步目录。
不要把系统应用私有目录作为主要同步目录。
需要同步相册时，优先选择 DCIM/Camera 这类普通媒体目录。
同步笔记时，建议放在 /storage/emulated/0/SyncData/Notes 这类清晰路径。

稳定比“路径看起来很原生”更重要。

不建议一开始同步整个：

`1`	`/storage/emulated/0`

这个目录太大、太杂，里面有缓存、下载、应用数据和临时文件，容易带来性能、权限和冲突问题。

手机端文件夹类型怎么选

不同场景可以这样选：

笔记双向同步

如果手机和电脑都会编辑同一批 Markdown 笔记：

`1`	`Send & Receive`

但要注意冲突。不要在多台设备上同时编辑同一个文件。

手机照片备份到 NAS

如果手机主要负责发送照片：

`1`	`Send Only`

NAS 端可以配合版本保留或快照。

手机只看资料

如果手机只需要拿到 NAS 上的资料，不希望手机误删影响其他设备：

`1`	`Receive Only`

例如把资料库、电子书、脚本参考文件同步到手机阅读。

删除策略要想清楚

很多人会问：手机删照片后，NAS 上会不会删？

这取决于文件夹类型和同步状态。为了减少误删风险，建议：

手机端使用 Send Only。
NAS 端使用 Receive Only。
NAS 端开启文件版本。
NAS 再做快照或独立备份。

如果你的真实目标是“归档”，还可以让 Syncthing 先同步到 NAS 的中转目录，再由 NAS 定时任务把文件复制到归档目录。归档目录不再由 Syncthing 管理。

例如：

1
2

/volume1/photos/inbox-phone
/volume1/photos/archive

Syncthing 只写入 inbox-phone，定时脚本再把照片整理到 archive。

常见问题

锁屏后不同步

优先检查：

是否加入电池优化白名单。
是否允许后台运行。
是否允许自启动。
是否启用了仅充电或仅 Wi-Fi 条件。

很多时候不是 Syncthing-Fork 配错了，而是系统后台管理把它限制住了。

找不到相册目录

先用系统文件管理器确认实际路径。常见路径是：

`1`	`/storage/emulated/0/DCIM/Camera`

如果使用第三方相机或修图 App，文件可能在其他目录。

同步很慢

检查：

手机和 NAS 是否在同一个 Wi-Fi。
是否走了 Relay。
NAS 端 22000/TCP 和 22000/UDP 是否可用。
手机是否处于省电模式。
是否有大量小文件。

大量小文件同步本来就比少量大文件慢。第一次同步完成后，后续增量通常会轻很多。

删除手机照片后 NAS 也删了

这说明你的同步关系把删除动作也同步过去了。Syncthing 是同步工具，不是天然只增不删的备份工具。

解决思路：

检查手机端和 NAS 端文件夹类型。
NAS 端开启文件版本。
NAS 再配合快照或独立备份。
如果目标是归档，考虑把手机照片同步到一个中转目录，再由 NAS 定时搬运到归档目录。

总结

Android 上使用 Syncthing，关键不是安装 App，而是处理好权限、后台、电池和网络条件。

Syncthing-Fork 更适合长期手机同步。它可以把同步限制在 Wi-Fi、指定 Wi-Fi 或充电状态下，既减少耗电，也避免移动流量偷跑。

如果你的目标是手机照片备份到 NAS，建议按单向备份思路配置：手机 Send Only，电脑或 NAS Receive Only，再配合 NAS 端文件版本、快照和独立备份。同步负责传输，真正的长期安全要靠备份策略兜底。

Syncthing 多设备怎么配？对等网络、星型拓扑和引入者

Sun, 31 May 2026 12:13:57 +0800

Syncthing 系列目录

Syncthing 采用的是去中心化 P2P 架构。它没有传统意义上的 Server 和 Client，每台设备在协议层面都是对等节点。

但在实际使用时，你可以把它配置成两种形态：

纯对等网络：每台设备都和其他设备直接配对。
星型网络：指定一台 NAS、服务器或常开电脑作为中心节点，其他设备只和它配对。

两种方式都符合 Syncthing 的设计，只是管理成本和使用习惯不同。

先理解“对等”和“伪服务器”

Syncthing 里的每台设备都有自己的 device ID。只要两台设备互相添加对方 ID，并且共享同一个文件夹，它们就能同步。

所以，Syncthing 本身没有“服务器端必须保存所有数据”这个概念。你看到的“服务器”，往往只是人为指定的一台常开设备。

比如：

NAS 长期开机、空间大，适合作为中心节点。
手机和笔记本经常离线，适合作为边缘设备。
台式机性能强，但不一定 24 小时开机，可以作为普通同步节点。

这个“中心节点”不是协议上的服务器，而是你在拓扑设计中让它承担管理和中转角色。

模式一：纯对等 Mesh 网络

纯对等模式下，每台设备都和其他所有设备配对。

例如你有四台设备：

NAS
台式机
笔记本
手机

那么每台设备都要和另外三台设备建立连接。这样任何两台在线设备之间都可以直接同步。

优点：

传输路径更直接。
某台设备离线时，其他在线设备仍然可以互相同步。
不依赖某一个中心节点。

缺点：

设备越多，配对关系越复杂。
新增设备时，需要在多台旧设备上确认和配置。
文件夹共享关系容易散。

设备数量少时，纯对等模式很舒服。比如只有一台电脑和一台手机，或者两台电脑互相同步笔记，就不需要想太复杂。

但当设备数量变成五六台以上，手动维护全连接关系会越来越麻烦。

模式二：以 NAS 为中心的星型拓扑

星型模式更适合家庭和个人生产力场景。

做法是：选一台长期开机、空间足够、网络稳定的设备作为中心节点，例如：

NAS
群晖
软路由
迷你主机
家用 Linux 服务器

然后其他设备只和它配对：

1
2
3

手机 ----\
笔记本 ---- NAS
台式机 ----/

手机不需要直接配对笔记本，笔记本也不需要直接配对台式机。它们都通过 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，等待几秒钟，通常会看到提示：

`1`	`设备 A 想共享一个文件夹`

点击添加，然后在设备 B 上指定本地存储路径。

例如：

`1`	`/volume1/notes`

或者 Docker 部署场景下的容器内路径：

`1`	`/var/syncthing/notes`

保存后，同步正式开始。

这里要注意：不同设备上的路径可以不一样。Syncthing 通过文件夹 ID 识别同步关系，不要求每台设备使用相同的本地路径。

星型拓扑怎么配置

如果你采用 NAS 中心模式，建议这样做：

先在 NAS 上部署 Syncthing。
所有手机、电脑、服务器都只和 NAS 配对。
在 NAS 上创建或接收主要同步文件夹。
每台新设备只添加 NAS 的 device ID。
需要同步哪个文件夹，就在 NAS 和对应设备之间共享。

例如：

NAS
├── notes       -> 台式机、笔记本、手机
├── photos      -> 手机、备份盘
├── downloads   -> 台式机、NAS
└── scripts     -> 台式机、笔记本

这样结构非常清楚。你可以把 NAS 当作同步关系的控制面。

引入者是什么

Syncthing 有一个很实用的功能：Introducer，中文界面里通常叫“引入者”。

它适合多设备场景。

假设你把 NAS 设置为引入者。之后新设备只要和 NAS 配对，NAS 就可以把它知道的其他设备介绍给新设备，也可以帮助同步已有的共享关系。

这样做可以减少重复点击和重复配对。

适合：

家里有多台电脑和手机。
NAS 作为长期中心节点。
经常新增设备。
希望减少手工维护设备关系。

但也要注意，引入者会扩大自动建立关系的范围。不要把不完全信任的设备设为引入者，也不要在不清楚拓扑的情况下随手勾选。

更稳妥的做法是：

只把 NAS 或主服务器设为引入者。
普通手机、笔记本不要设为引入者。
新设备加入后，检查它被自动添加了哪些设备和文件夹。

文件夹类型决定数据方向

Syncthing 的权限控制主要体现在文件夹类型上。

进入文件夹设置，在选项里可以调整 Folder Type。

常见三种：

Send & Receive

默认模式。双方都可以发送和接收变更。

适合：

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

这是最接近“真正对等”的模式。

Send Only

本机只发送，不接收其他设备的变更。

适合：

数据源头。
主目录向其他设备分发。
不希望远端修改影响本机。

例如你把 NAS 上的某个软件安装包目录设置为 Send Only，让其他电脑只接收。

Receive Only

本机只接收，不把本地改动发送出去。

适合：

备份机。
只读镜像。
防止本地误删反向影响主目录。

例如 NAS 用来接收手机照片，手机端删除照片时，你不希望 NAS 也跟着删，就要认真设计文件夹类型和删除策略。

不同目录可以用不同拓扑

Syncthing 的拓扑不一定全站统一。你可以按文件夹设计。

例如：

notes：电脑、笔记本、手机、NAS 都使用 Send & Receive。
photos：手机发送，NAS 接收并保留版本。
downloads：NAS 和台式机同步，手机不参与。
backup：主电脑 Send Only，NAS Receive Only。

不要把所有目录都套进一种规则。多设备同步真正重要的是数据方向，而不是设备数量。

冲突和误删要提前想

多设备同步最常见的问题不是配置失败，而是同步成功之后发生误删或冲突。

容易出问题的场景：

两台设备同时编辑同一个文件。
手机端应用自动清理目录。
一台设备路径填错，创建了空目录并同步过去。
把缓存、临时文件、工作区状态文件一起同步。
NAS 端没有开启版本保留。

建议：

重要目录在 NAS 上开启文件版本。
使用 .stignore 排除缓存和临时文件。
新文件夹第一次同步前，先用少量测试文件验证。
不确定删除策略时，不要把所有设备都设为 Send & Receive。

总结

Syncthing 是 P2P 对等架构，但不代表你必须把所有设备配成复杂网状结构。

小规模设备可以用纯对等模式；设备多、有 NAS 或常开主机时，更建议使用星型拓扑。让 NAS 承担中心节点和引入者角色，其他设备只跟 NAS 建立关系，管理会简单很多。

真正要想清楚的是：哪些设备可信、哪些目录要同步、数据从哪里来、误删时谁负责保留版本。拓扑只是手段，数据流向才是配置的核心。

用 Docker 部署 Syncthing：Compose、端口和目录映射避坑

Sun, 31 May 2026 12:12:05 +0800

Syncthing 系列目录

在 Docker 中部署 Syncthing 很适合 NAS、家用服务器和 VPS 场景。它可以作为 24 小时在线的同步节点，长期承担照片、文档、Markdown 笔记或下载目录的同步任务。

Docker 部署 Syncthing 的重点不是“能不能跑起来”，而是三个问题：

配置目录要持久化。
需要同步的数据目录要映射到宿主机。
端口和权限要提前处理好。

如果这三点没处理好，容器更新后可能丢配置，Web UI 里填写路径时可能找不到真实目录，或者同步时报 Permission denied。

目录规划

建议先在服务器或 NAS 上准备一个独立目录，例如：

1
2

mkdir -p ~/syncthing
cd ~/syncthing

这个目录里放 docker-compose.yml，并用子目录保存 Syncthing 配置：

1
2
3

syncthing/
├── docker-compose.yml
└── config/

同步数据目录可以放在 NAS 或宿主机已有路径中，例如：

1
2

/volume1/downloads
/volume1/photos

配置目录和数据目录要分开。config 保存 Syncthing 自己的配置、密钥和索引数据库；downloads、photos 这类目录才是你要同步的真实数据。

方案一：Docker Compose

更推荐使用 Docker Compose，后续更新、重启和迁移都更清楚。

在 ~/syncthing/docker-compose.yml 写入：

version: "3"

services:
  syncthing:
    image: syncthing/syncthing:latest
    container_name: syncthing
    hostname: my-nas-syncthing
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    volumes:
      - ./config:/var/syncthing/config
      - /volume1/downloads:/var/syncthing/downloads
      - /volume1/photos:/var/syncthing/photos
    ports:
      - 8384:8384
      - 22000:22000/tcp
      - 22000:22000/udp
      - 21027:21027/udp
    restart: unless-stopped

启动：

`1`	`docker compose up -d`

查看状态：

1
2

docker compose ps
docker logs -f syncthing

打开 Web UI：

`1`	`http://服务器IP:8384`

首次进入后台后，先设置 GUI 用户名和密码。

方案二：docker run

如果只是快速测试，也可以直接使用 docker run：

docker run -d \
  --name syncthing \
  --hostname my-nas-syncthing \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Asia/Shanghai \
  -p 8384:8384 \
  -p 22000:22000/tcp \
  -p 22000:22000/udp \
  -p 21027:21027/udp \
  -v /path/to/config:/var/syncthing/config \
  -v /path/to/data1:/var/syncthing/data1 \
  --restart unless-stopped \
  syncthing/syncthing:latest

这里的 /path/to/config 和 /path/to/data1 必须换成宿主机真实路径。

例如：

1
2

-v /volume1/docker/syncthing/config:/var/syncthing/config
-v /volume1/photos:/var/syncthing/photos

长期使用时，还是建议改成 Compose 文件，避免每次重建容器都要重新拼命令。

容器内路径和宿主机路径

Docker 新手最容易混淆的是路径。

比如 Compose 里写了：

1
2

volumes:
  - /volume1/photos:/var/syncthing/photos

左边 /volume1/photos 是宿主机路径。右边 /var/syncthing/photos 是容器内路径。

进入 Syncthing Web UI 添加同步文件夹时，文件夹路径必须填写容器内路径：

`1`	`/var/syncthing/photos`

这样 Syncthing 实际操作的才是宿主机上的：

`1`	`/volume1/photos`

如果你在 Web UI 里填 /volume1/photos，容器内部通常并没有这个路径，Syncthing 可能会报错，或者在容器文件系统里创建一个你并不想要的新目录。

配置目录必须持久化

下面这一行很关键：

`1`	`- ./config:/var/syncthing/config`

Syncthing 的配置文件、设备密钥和索引数据库都会放在配置目录里。如果不把它挂载到宿主机，容器删除或重建后，设备 ID 可能变化，原来的设备配对关系也会失效。

建议把配置目录放在稳定路径中，例如：

`1`	`/volume1/docker/syncthing/config`

不要把配置目录放进临时目录，也不要和同步数据目录混在一起。

端口和防火墙

常用端口如下：

8384/TCP   Web UI 管理后台
22000/TCP 设备间同步流量
22000/UDP QUIC 同步流量
21027/UDP 局域网发现

如果 Syncthing 部署在家用 NAS 上，通常要检查：

NAS 自带防火墙是否放行这些端口。
Docker 网桥端口是否正确映射。
路由器是否隔离了 Wi-Fi 和有线网络。
手机和电脑是否在同一网段。

如果部署在云服务器上，还要检查云厂商安全组。尤其是 22000/TCP 和 22000/UDP，如果没有放行，其他设备可能只能通过 relay 连接，速度会明显变慢。

8384 是管理后台端口，不建议直接暴露到公网。如果确实要远程管理，至少要设置强密码，最好再配合反向代理、HTTPS、访问控制或 VPN。

权限问题：PUID 和 PGID

如果启动后 Syncthing 能打开 Web UI，但同步目录时报：

`1`	`Permission denied`

通常是容器进程没有宿主机目录的读写权限。

先在宿主机上查看当前用户的 UID 和 GID：

id

输出类似：

`1`	`uid=1000(user) gid=1000(user) groups=1000(user)`

然后把 Compose 里的环境变量改成对应值：

1
2
3

environment:
  - PUID=1000
  - PGID=1000

同时确认宿主机目录本身允许这个用户读写：

`1`	`ls -ld /volume1/photos`

必要时调整目录所有者或权限：

`1`	`sudo chown -R 1000:1000 /volume1/photos`

在 NAS 系统上不要盲目递归改整个共享目录权限，尤其是多人共享目录。更稳妥的做法是给 Syncthing 单独准备一个同步目录，或者在 NAS 权限管理界面给对应用户授权。

Web UI 首次安全设置

容器启动后，访问：

`1`	`http://服务器IP:8384`

首次进入后台，Syncthing 通常会提示设置 GUI 用户名和密码。这个步骤不要跳过。

建议：

立即设置 GUI 用户名和强密码。
不把 8384 暴露到公网。
远程访问时优先走 VPN、SSH 隧道或受控反向代理。
如果使用反向代理，确认只代理 Web UI，不要误开放其他不必要端口。

如果管理后台被别人控制，对方就可能添加设备、修改共享目录、改变同步关系。Syncthing 的同步数据传输是加密的，但管理入口本身仍然需要保护。

在 Web UI 中添加同步目录

以照片目录为例，Compose 中已经挂载：

`1`	`- /volume1/photos:/var/syncthing/photos`

Web UI 里添加文件夹时：

Folder Label：可以写 Photos。
Folder ID：建议使用稳定英文 ID，例如 photos。
Folder Path：填写 /var/syncthing/photos。
Sharing：选择要共享给哪些设备。
Folder Type：按需求选择 Send & Receive、Send Only 或 Receive Only。

如果这台 Docker 节点是 NAS 中心节点，常见配置是：

普通文档：Send & Receive
手机照片汇总：NAS 上设为 Receive Only
对外分发目录：NAS 上设为 Send Only

具体选择要看你的数据流向。不要所有目录都无脑双向同步。

更新容器

使用 Compose 时，更新通常是：

1
2

docker compose pull
docker compose up -d

只要配置目录和数据目录都正确挂载，更新容器不会丢失设备 ID、配对关系和同步目录配置。

更新前可以先备份配置目录：

`1`	`tar -czf syncthing-config-backup.tar.gz ./config`

配置目录里包含设备私钥，不要把备份文件随便上传到公共位置。

常见问题

Web UI 打不开

先检查容器是否运行：

1
2

docker ps
docker logs syncthing

再检查端口映射：

`1`	`docker port syncthing`

如果容器正常，仍然打不开，检查宿主机防火墙、NAS 防火墙或云服务器安全组。

添加目录后提示不存在

检查你在 Web UI 里填写的是不是容器内路径。

例如宿主机路径是：

`1`	`/volume1/downloads`

容器内路径是：

`1`	`/var/syncthing/downloads`

Web UI 里应该填后者。

只能通过 Relay，速度很慢

优先检查：

22000/TCP 是否放行。
22000/UDP 是否放行。
路由器端口转发是否正确。
云服务器安全组是否同时放行 TCP 和 UDP。
本机防火墙是否拦截 Docker 映射端口。

Relay 能提高可连接性，但不适合长期承担大量同步流量。

同步后文件权限不对

先确认容器运行用户是否正确，再确认宿主机目录权限。Linux、NAS、Windows 共享目录之间的权限模型不同，不要把 Syncthing 当成权限修复工具。

对于跨系统同步，尽量同步普通文件和目录，少同步依赖复杂 ACL、所有者、扩展属性的系统目录。

一个更稳的使用方式

如果你的目标是把 NAS 或服务器作为中心节点，可以这样设计：

NAS 上用 Docker 跑 Syncthing。
配置目录挂载到 /volume1/docker/syncthing/config。
每类数据单独挂载，例如 /volume1/photos、/volume1/notes。
手机、电脑分别添加 NAS 的设备 ID。
重要目录在 NAS 端开启文件版本。
Web UI 只在内网或 VPN 内访问。
NAS 本身再做独立备份，不把同步当作唯一备份。

这样 Syncthing 负责设备间同步，NAS 负责长期在线和版本缓冲，真正的备份再交给快照、外接硬盘或异地备份。

总结

Docker 部署 Syncthing 的关键是把“容器生命周期”和“同步数据生命周期”分开。

容器可以随时更新、重建、迁移；但配置目录和数据目录必须稳定保存在宿主机上。Web UI 里填写的是容器内路径，宿主机权限要通过 PUID、PGID 和目录授权处理，端口要按实际网络环境放行。

只要这几件事配置清楚，Syncthing 很适合作为 NAS、服务器和个人设备之间的轻量同步层。

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

Sun, 31 May 2026 11:59:09 +0800

Syncthing 系列目录

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，才会建立连接并同步。

实际操作顺序通常是：

在两台设备上都启动 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 等机制让设备互相找到，但网络越清楚，连接越稳定。

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

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 编码。

一个简单例子：

(?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 长期同步笔记或文档，可以按这个思路配置：

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

适合和不适合

Syncthing 适合：

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

Syncthing 不太适合：

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

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

Syncthing on KnightLi的博客

Syncthing 多设备多文件夹怎么管理？拓扑、命名和版本控制

Syncthing 系列目录

拓扑：放弃全连接，优先星型

Folder ID 比文件夹标签更重要

中心节点路径要规范

引入者：减少多设备配对成本

区分备份和双向同步

手机照片备份

多端文档和笔记

资料分发

备份目录

NAS 上开启文件版本控制

用忽略规则过滤临时文件

多文件夹命名示例

推荐整体方案

总结

Syncthing 如何同步 iPhone 照片到电脑或 NAS

Syncthing 系列目录

先理解 iOS 上的限制

第一步：安装客户端并授予权限

通知权限

本地网络权限

相册访问权限

第二步：iPhone 和电脑/NAS 配对

第三步：在 iPhone 上创建相册同步文件夹

第四步：iPhone 端设为 Send Only

第五步：在电脑或 NAS 端接收照片

接收端建议设为 Receive Only

iOS 后台同步的现实限制

避免 iCloud 优化存储影响同步

大量照片首次同步建议

推荐配置

总结

Android 上怎么用 Syncthing？Syncthing-Fork 配置与照片备份

Syncthing 系列目录

为什么更推荐 Syncthing-Fork

安装来源

第一步：授予必要权限

存储权限

电池优化白名单

第二步：和 NAS 或电脑配对

第三步：接收 NAS 或电脑共享的文件夹

第四步：把手机照片备份到电脑或 NAS

手机端添加相册文件夹

手机端改为 Send Only

接收端设置保存路径

接收端改为 Receive Only

第一次同步前先小规模测试

运行条件：防止偷跑流量

充电时同步：更省电的工作流

Android 11 之后的存储限制

手机端文件夹类型怎么选

笔记双向同步

手机照片备份到 NAS

手机只看资料

删除策略要想清楚

常见问题

锁屏后不同步

找不到相册目录

同步很慢

删除手机照片后 NAS 也删了

推荐配置

总结

Syncthing 多设备怎么配？对等网络、星型拓扑和引入者

Syncthing 系列目录

先理解“对等”和“伪服务器”

模式一：纯对等 Mesh 网络

模式二：以 NAS 为中心的星型拓扑

多设备配置的基本顺序

第一步：设备互联

第二步：创建并共享文件夹

第三步：接收共享

星型拓扑怎么配置

引入者是什么

文件夹类型决定数据方向

Send & Receive

Send Only

Receive Only

不同目录可以用不同拓扑

`.stignore` 要放在同步根目录