多台机器之间同步文件，很多人第一反应是云盘——上传到中心服务器，再从另一台下载。Syncthing 走的是另一条路：设备之间直接传输，没有中间人，数据不落地第三方。2.1.0 版本带来了 GUI 分组、代理增强等改进，让管理多设备同步场景变得更清晰。
直连同步，为什么值得关注
Syncthing 的核心模型是点对点：你的笔记本直接和家里的 NAS、办公室的台式机建立 TLS 连接，文件块通过 Block Exchange Protocol 传输。这意味着：
- 没有第三方服务器存储你的数据，隐私边界由你自己划定。
- 两台机器在同一局域网时，传输速度接近原生网络带宽，不绕公网。
- 每个设备有唯一 Device ID（基于证书），你可以精确控制谁能连接谁。
对于开发者常见的场景——代码仓库在多台机器间保持一致、大型数据集在服务器和本地之间流转、配置文件跨设备同步——Syncthing 比 Git 更适合二进制和大文件，比 rsync 更适合持续双向同步。
2.1.0 的新东西：设备与文件夹分组
当你在 Syncthing 里管理十几个设备、几十个共享文件夹时，GUI 里的列表会变得很长，找东西费眼。2.1.0 引入了 group 属性，你可以在 Web GUI 中给设备和文件夹打上分组标签，然后按组筛选和折叠显示。
分组不是只影响显示——它也帮你理清同步拓扑。比如你可以把"生产服务器"归一组、"开发机"归一组、"家庭成员设备"归一组，一眼看出哪些文件夹在哪些组之间共享。
在配置文件中，分组是这样设置的：
<!-- ~/.local/state/syncthing/config.xml 中的设备配置片段 -->
<device id="DEVICE-ID-HERE" name="nas-home" compression="metadata">
<group>生产服务器</group>
</device>
<folder id="data-raw" path="/mnt/data/raw" type="sendreceive" rescanIntervalS="3600">
<group>数据集</group>
</folder>
修改配置后重启 Syncthing 服务，或在 GUI 中直接编辑设备/文件夹的 Group 字段即可生效。GUI 左侧会出现分组筛选器，点击某个组就能只看该组下的条目。
快速上手：从安装到第一个同步文件夹
下面是一个完整的本地两节点测试流程，你可以在一台机器上跑两个 Syncthing 实例来验证同步行为。
# 1. 安装 Syncthing（macOS 用 Homebrew，Linux 用官方 APT 源或直接下载二进制）
brew install syncthing # macOS
# 或 Linux:
# curl -fsSL https://syncthing.net/release-key.gpg | sudo tee /usr/share/keyrings/syncthing-archive-keyring.gpg >/dev/null
# echo "deb [signed-by=/usr/share/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list
# sudo apt-get update && sudo apt-get install syncthing
# 2. 启动第一个实例（默认端口 8384）
syncthing
# 3. 启动第二个实例用于测试（不同端口，不同配置目录）
syncthing -home=/tmp/syncthing-node2 -gui-address=127.0.0.1:8385 -no-browser
# 4. 在两个 GUI 中互相添加对方 Device ID（GUI 首页右上角可复制本机 ID）
# 然后在任一侧创建一个共享文件夹，指定对方设备为共享目标
# 5. 创建测试文件夹并观察同步
mkdir -p ~/syncthing-test/node1
# 在 GUI 中添加该路径为 Folder，选择 Send & Receive 模式
# 在 node2 的 GUI 中接受共享，设置本地路径为 /tmp/syncthing-node2-recv
echo "hello from node1" > ~/syncthing-test/node1/test.txt
# 几秒后检查 /tmp/syncthing-node2-recv/test.txt 是否出现
这个双节点测试能让你直观看到：文件创建后几秒内就出现在另一端，修改也会双向传播。遇到冲突时，Syncthing 会保留两个版本（文件名加 .sync-conflict 后缀），不会静默覆盖。
SOCKS 代理与网络控制
2.1.0 继续完善了代理支持。如果你的设备需要通过 SOCKS5 代理才能到达对端（比如公司网络限制直连），可以在配置中指定：
<options>
<globalAnnounceEnabled>false</globalAnnounceEnabled> <!-- 关闭全球发现，只用本地发现 -->
<relayEnabled>false</relayEnabled> <!-- 关闭中继 -->
</options>
<device id="REMOTE-DEVICE-ID" name="remote-via-proxy">
<group>远程设备</group>
<!-- 在 GUI 的设备编辑页面 → Advanced → Proxy 设置 SOCKS5 地址 -->
</device>
在 GUI 中：打开设备编辑页面 → Advanced 栀签 → 填写 socks5://proxy-host:1080。这样与该设备的所有连接都走指定代理，其他局域网设备仍然直连。这种按设备区分代理的策略，比全局代理更灵活——你不必为了一个远程设备把所有流量都绕出去。
日常运维的几个实用命令
# 查看 Syncthing 服务状态
syncthing --status
# 强制重新扫描某个文件夹（配置变更后有用）
curl -X POST http://localhost:8384/api/db/rescan?folder=folder-id \
-H "X-API-Key: YOUR-API-KEY"
# 查看最近的事件日志（排查同步延迟）
curl http://localhost:8384/api/events?limit=20 \
-H "X-API-Key: YOUR-API-KEY"
# 忽略特定文件（在每个同步文件夹下创建 .stignore 文件）
echo "*.tmp" >> ~/syncthing-test/node1/.stignore
echo ".DS_Store" >> ~/syncthing-test/node1/.stignore
echo "node_modules/" >> ~/syncthing-test/node1/.stignore
.stignore 的语法类似 gitignore，但只作用于 Syncthing 的扫描范围。对于开发者来说，忽略 node_modules、构建产物、临时文件是必须的——否则同步引擎会浪费大量带宽扫描几万个不会变化的文件。
上手建议与边界提醒
适合用 Syncthing 的场景： - 多台个人设备间同步代码项目、文档、照片（双向、持续） - 服务器之间同步数据目录（配合 Send Only 模式，单向推送） - 团队内部共享大型数据集，不想上传到公有云
不太适合的场景： - 需要版本历史回溯和分支管理的代码协作——这是 Git 的领域 - 百人以上规模的实时协作编辑——Syncthing 的冲突处理是"保留两份"，不是自动合并 - 对同步延迟要求毫秒级的场景——Syncthing 的扫描间隔默认 60 秒，可调但不是事件级触发
升级到 2.1.0 的检查清单：
1. 备份现有配置：cp ~/.local/state/syncthing/config.xml config.xml.bak
2. 升级后打开 GUI，为现有设备和文件夹补充 group 属性——哪怕只是粗分"本地/远程"，也比平铺列表好找
3. 如果有设备需要走代理，逐个在 Advanced 里配置 SOCKS 地址，不要全局设置
4. 检查 .stignore 是否覆盖了新增的文件夹路径
Syncthing 2.1.0 的分组功能看似只是 UI 改进，但当你管理超过 5 台设备时，它确实减少了"找那个文件夹到底共享给了谁"的摩擦。加上按设备配置代理的能力，多网络环境下的同步拓扑变得更可控。如果你还没用过 Syncthing，花十分钟跑一下上面的双节点测试，比读任何文档都直观。