运维 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 能力，又把日常管理收束到一台中心设备上。设备再多，文件夹再多，也不会变成一团乱线。

用 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、服务器和个人设备之间的轻量同步层。

CVE-2026-42945 怎么排查？Nginx Rift 漏洞触发条件、版本检查与升级建议

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 是 NGINX Open Source 和 NGINX Plus 中的一个安全漏洞，外界也把它称为 Nginx Rift。它出现在 ngx_http_rewrite_module，漏洞类型是 heap-based buffer overflow。

这类新闻很容易被写成“潜伏 18 年”“不用密码远程控制”“三成服务器中招”。这些说法有传播性，但看补丁和 NVD 描述时，最好把风险拆开看：它确实严重，也确实不需要登录账号；但并不是所有 Nginx 实例都会自动被接管，触发需要特定 rewrite 配置和请求条件。

先看官方描述

NVD 对 CVE-2026-42945 的描述可以概括为：

影响 NGINX Plus 和 NGINX Open Source。
漏洞位于 ngx_http_rewrite_module。
当 rewrite 指令后面跟着 rewrite、if 或 set 指令，并且使用未命名的 PCRE 捕获组，例如 $1、$2，同时替换字符串里包含问号 ? 时，可能触发问题。
未认证攻击者可以发送构造请求触发漏洞。
结果可能是 NGINX worker 进程发生 heap buffer overflow 并重启。
如果系统关闭了 ASLR，存在代码执行可能。

F5 作为 CNA 给出的评分是：

CVSS v4.0：9.2，Critical。
CVSS v3.1：8.1，High。
CWE：CWE-122 Heap-based Buffer Overflow。

所以，这不是普通的“配置写错导致 404”问题，而是 Nginx 官方安全修复范围内的内存安全漏洞。

哪些说法需要降温

第一，“不用密码”基本可以理解为未认证攻击。也就是说，攻击者不需要登录 Nginx 后台，不需要拿到 SSH，也不需要应用系统账号。但这不等于任何公网 Nginx 都能被随手接管。

第二，“直接远程控制”要看条件。官方描述里更稳妥的说法是：漏洞可导致 worker 进程重启；在 ASLR 关闭的系统上，代码执行是可能结果。对启用了 ASLR、发行版编译加固完整、运行权限受限的环境，风险路径会更复杂。

第三，“30% 服务器中招”不能简单等同于“所有 Nginx 市占率都是漏洞暴露面”。真正暴露要同时看版本、是否启用受影响模块、是否存在特定 rewrite 配置、发行版是否已经回补补丁，以及 Nginx 运行环境的加固状态。

更准确的判断方式是：只要你在生产环境运行 Nginx，就应该尽快检查；但不要只按标题里的比例判断自己是否中招。

受影响范围怎么判断

从 nginx.org 发布信息看，2026 年 5 月 13 日发布的 nginx-1.30.1 stable 和 nginx-1.31.0 mainline 包含多项安全修复，其中包括 ngx_http_rewrite_module 的 buffer overflow，也就是 CVE-2026-42945。

如果你使用官方 Nginx 源码或官方包，可以优先关注：

NGINX Open Source stable：升级到 1.30.1 或之后版本。
NGINX Open Source mainline：升级到 1.31.0 或之后版本。
NGINX Plus：查看 F5 对应分支的修复版本。

如果你使用 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine、容器镜像、Plesk、宝塔、Ingress Controller 或云厂商托管组件，不要只看 nginx -v 里的上游版本号。很多发行版会把安全补丁 backport 到旧版本包里，版本号看起来旧，但补丁可能已经合入。

一分钟判断是否需要紧急处理

可以先按下面几个问题快速分级：

这台 Nginx 是否直接暴露在公网，或者位于 API Gateway、反向代理、负载均衡、Ingress 入口层？
是否使用官方 Nginx 包、源码编译包、第三方面板、容器镜像，且还没有确认 CVE-2026-42945 修复状态？
配置里是否存在复杂 rewrite 规则，尤其是连续 rewrite、if、set，以及 $1、$2 这类未命名捕获组？
是否存在把请求路径、查询参数或用户可控输入带入 rewrite 目标的场景？
系统加固是否较弱，例如 ASLR 被关闭、worker 权限过高、容器权限过宽？

如果前两项命中，并且 rewrite 配置还没有排查，建议按高优先级处理。公网入口、共享环境、Kubernetes Ingress、边缘代理和承载登录/API 流量的 Nginx，应该优先升级或替换到确认修复的包。

Debian / Ubuntu / RHEL / Alpine 如何确认修复

发行版用户不要只看 nginx -v。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine 这类系统经常把安全补丁回补到稳定分支，表面版本号可能仍然低于 nginx.org 的 1.30.1 或 1.31.0。

Debian / Ubuntu 可以优先看安全公告、包 changelog 和可升级列表：

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

RHEL / AlmaLinux / Rocky Linux 可以看安全更新和包变更记录：

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

Alpine 可以检查当前包版本和安全分支更新：

1
2

apk info -v nginx
apk version -v nginx

如果包管理器、发行版安全公告或厂商 advisory 明确写明已修复 CVE-2026-42945，即使上游版本号看起来不新，也可以按“已回补修复”处理。反过来，如果只是版本号较高但来源不明，仍然要确认构建日期和补丁来源。

容器镜像与 Ingress Controller 怎么查

容器环境要检查镜像里的 Nginx，而不是只看宿主机。先确认镜像实际内置版本：

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

还要看基础镜像是否更新过。如果镜像基于 Debian、Ubuntu、Alpine 或发行版包构建，判断方式应回到对应发行版的安全公告和包 changelog。只重启旧镜像没有意义，镜像本身需要重新构建或替换。

Kubernetes Ingress 需要同时确认三件事：

Ingress Controller 项目是否发布了针对 CVE-2026-42945 的 advisory 或修复版本。
当前集群运行的 controller 镜像 digest 是否已经更新，而不是只改了 tag。
controller 内置 Nginx 版本、构建参数和模板配置是否仍然包含高风险 rewrite 规则。

可以先看运行中的镜像：

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

如果使用云厂商托管 Ingress 或网关，还要查对应云服务公告。托管组件通常不是用户自己 apt upgrade 能解决的，需要等待厂商修复或切换到已修复版本。

rewrite 配置重点排查哪些写法

这个漏洞和 rewrite 配置有关，排查时可以先搜索 Nginx 配置：

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

重点关注类似模式：

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

这里的 $1、$2 这类未命名捕获组，以及替换目标中的 ?，是官方描述里的关键条件之一。排查时尤其关注下面几类写法：

一个 rewrite 后面紧跟另一个 rewrite、if 或 set。
正则里使用 (.*)、(.+) 这类宽泛捕获，并在目标里用 $1、$2。
rewrite 目标里带 ?，用于拼接或丢弃查询参数。
rewrite 输入来自公网路径、Host、URI、参数或上游可控值。
面板、网关、Ingress 注解或模板自动生成的 rewrite 规则。

如果短时间内无法升级，可以先做临时缓解：

减少复杂 rewrite 规则。
把未命名捕获组改成更清晰的命名捕获。
避免在替换字符串里拼接不必要的 ?。
对高风险入口加 WAF 或反向代理规则。
确认系统启用了 ASLR。
降低 Nginx worker 运行权限，确认 systemd sandbox、SELinux/AppArmor 等加固状态。

这些只是缓解，不是替代补丁。

修复优先级

建议按暴露面排序：

公网入口 Nginx。
反向代理、API Gateway、边缘网关。
多租户环境里的 Nginx。
Kubernetes Ingress Controller。
Plesk、面板工具、云市场镜像等自带 Nginx 的组件。
内网但承载关键业务的 Nginx。

升级后如何验证：nginx -t、reload、worker 状态

更新后不要只看包管理器提示成功，还要确认配置、进程和实际二进制都已经切换。先验证配置：

`1`	`nginx -t`

确认没有错误后再平滑加载：

`1`	`systemctl reload nginx`

如果包升级涉及二进制替换，建议确认旧 worker 已退出：

`1`	`ps aux \| grep nginx`

也可以查看主进程启动时间和二进制路径，确认运行中的服务不是旧进程继续驻留。必要时安排维护窗口重启服务，避免旧 worker 或旧容器继续处理请求。

容器和 Ingress 环境还要确认新镜像已经真正滚动完成：

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

验证重点不是“命令执行过”，而是“线上流量已经由包含修复的 Nginx 进程承载”。

不要忽略同批次 Nginx 修复

nginx.org 在同一天发布的 1.30.1 和 1.31.0 不只修复了 CVE-2026-42945。发布信息还提到 HTTP/2 request injection、SCGI/uWSGI buffer overread、charset module buffer overread、HTTP/3 address spoofing、OCSP resolver use-after-free 等问题。

这意味着生产环境不应该只针对单个 CVE 做临时规则，而是应该把 Nginx 这一轮安全更新当成一次整体升级来处理。

小结

CVE-2026-42945 的关键点不是“所有 Nginx 都会被秒控”，而是：一个长期存在于 rewrite 模块里的内存安全漏洞，在特定配置下可被未认证请求触发，最直接后果是 worker 崩溃重启；在 ASLR 关闭等较弱环境下，代码执行风险更高。

对运维来说，处理顺序很简单：

确认 Nginx 来源和版本。
查看发行版、F5、nginx.org 或云厂商公告。
尽快升级到包含修复的版本或发行版安全包。
排查复杂 rewrite 配置，尤其是 $1、$2 和 ? 组合。
确认 ASLR、权限隔离和服务重载状态。

标题可以吓人，修复要冷静。先确认暴露面，再升级，再回头清理高风险 rewrite 规则。

参考链接

rsync --delete 参数详解与清空目录实践

Sun, 29 Mar 2026 11:00:00 +0800

rsync --delete 的核心作用是：删除目标目录中“源目录不存在”的文件，从而让目标端与源端保持一致。

它常用于以下场景：

同步时清理目标端的历史冗余文件
借助空目录快速清空目标目录

基础语法

`1`	`rsync -a --delete 源目录/ 目标目录/`

-a：归档模式，保留权限、时间戳等属性
--delete：删除目标端中多出的文件

关键注意：源目录 末尾是否带 / 会影响同步行为。带 / 表示同步目录内容，不带 / 表示同步目录本身。

如果你的目标是“保留目录结构但清空内容”，可以让一个空目录作为源进行同步：

# 1) 创建空目录
mkdir -p /tmp/empty_dir

# 2) 同步并删除目标目录中的内容
rsync -a --delete /tmp/empty_dir/ /path/to/target_dir/

这种方式在大目录场景下通常比逐个删除更高效，也更容易写入自动化脚本。

常用扩展参数

--delete-before：先删除再传输，某些场景下效率更高
--progress：显示传输与处理进度

示例（清理 Nginx 日志目录）：

`1`	`rsync -a --delete --progress /tmp/empty_dir/ /var/log/nginx/`

使用建议

先用 --dry-run 预演，确认删除范围再执行
在生产环境使用前，建议先做一次目标目录备份
对关键路径执行时，优先在低峰时段操作

运维 on KnightLi的博客

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

Syncthing 系列目录

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

Folder ID 比文件夹标签更重要

中心节点路径要规范

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

区分备份和双向同步

手机照片备份

多端文档和笔记

资料分发

备份目录

NAS 上开启文件版本控制

用忽略规则过滤临时文件

多文件夹命名示例

推荐整体方案

总结

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

Syncthing 系列目录

目录规划

方案一：Docker Compose

方案二：docker run

容器内路径和宿主机路径

配置目录必须持久化

端口和防火墙

权限问题：PUID 和 PGID

Web UI 首次安全设置

在 Web UI 中添加同步目录

更新容器

常见问题

Web UI 打不开

添加目录后提示不存在

只能通过 Relay，速度很慢

同步后文件权限不对

一个更稳的使用方式

总结

CVE-2026-42945 怎么排查？Nginx Rift 漏洞触发条件、版本检查与升级建议

先看官方描述

哪些说法需要降温

受影响范围怎么判断

一分钟判断是否需要紧急处理

Debian / Ubuntu / RHEL / Alpine 如何确认修复

容器镜像与 Ingress Controller 怎么查

rewrite 配置重点排查哪些写法

修复优先级

升级后如何验证：nginx -t、reload、worker 状态

不要忽略同批次 Nginx 修复

小结

参考链接

rsync --delete 参数详解与清空目录实践

基础语法

用空目录快速清空目标目录

常用扩展参数

使用建议