diff --git a/docs/content/WRITING.md b/docs/content/WRITING.md
index c80cbe88..7dda0718 100644
--- a/docs/content/WRITING.md
+++ b/docs/content/WRITING.md
@@ -65,6 +65,9 @@ ## 2 当前文章登记
| cfw-mac-legacy | 210 / Mac | Clash Verge Rev 使用教程：Mac 安装、订阅与系统代理 | `/a/m173.html` | [verge-mac.md](tutorials/verge-mac.md)；本地API版本2 | Mac操作入口；#install DMG安装，#import 订阅，系统代理与退出排错；无设备联网实测 |
| cfw-linux-legacy | 211 / Linux | Clash Verge Rev 使用教程：Linux 安装、订阅与代理设置 | `/a/m174.html` | [verge-linux.md](tutorials/verge-linux.md)；本地API版本5 | Linux桌面入门；#install 包格式与架构，#import 订阅，#terminal 单条curl代理验证；不适用于无桌面的服务器 |
| system-proxy-vs-tun | 365 / 综合教程 | 系统代理和 TUN 有什么区别？接管范围、使用选择与排错 | `/a/system-proxy-vs-tun.html` | [system-proxy-tun.md](tutorials/system-proxy-tun.md)；本地API版本1 | 桌面代理接管与出口选择；`#choose` 场景选择、`#switch` 切换检查、`#troubleshoot` 排错；三张流程图 |
+| clash-routing-modes | 366 / 综合教程 | Clash 规则、全局和直连怎么选？代理组与分流排错教程 | `/a/clash-rule-global-direct.html` | [clash-routing-modes.md](tutorials/clash-routing-modes.md)；2026-10-31本地ID366/版本1，正式ID382/版本1已发布 | 模式选择与代理组分流；`#groups` 组内选择、`#custom` 添加规则、`#verify` 验证新连接 |
+
+2026-10-31新教程正式ID382/版本1、本地ID366/版本1已发表；系统代理/TUN正文补入口后两环境均为API版本2（正式ID376、本地ID365）。正式发布时间14:58:28北京时间，IndexNow由VPS-003提交返回200，服务器HTTP与图哈希/锚点验收通过。唯一状态与恢复记录见[规则模式教程发布记录](../maintenance/ROUTING_MODES_2026-10-31.md)。
这里只登记长期编辑内容及值得复用的稳定资源说明，不逐条收录日更节点或账号文章。稳定入口为 `/freenode`（公开免费节点）、`/client`（入门）、`/advanced`（综合教程）；平台入口和名称修改另按项目路由核对，不从名称自行拼接。
@@ -105,6 +108,10 @@ ## 3 已有文章关系
| system-proxy-vs-tun | cfw-mac-legacy `#enable` | 切换前完成 Mac 基本连接 | 已在本地正文实现 |
| system-proxy-vs-tun | cfw-linux-legacy `#connect` / `#terminal` | Linux 基础连接及单条命令显式代理 | 已在本地正文实现 |
| system-proxy-vs-tun | mihomo-dns `#dns-2` | 继续检查 DNS 接管、加密和出口 | 已在本地正文实现 |
+| system-proxy-vs-tun | clash-routing-modes `#groups` | 已接管但走错出口时检查规则和代理组；放在场景选择之前 | 2026-10-31本地与正式已发布 |
+| clash-routing-modes | verge-windows-start `#enable` / cfw-mac-legacy `#enable` | 尚未完成基本连接时返回对应平台操作 | 2026-10-31本地与正式已发布 |
+| clash-routing-modes | system-proxy-vs-tun `#routing` / `#troubleshoot` | 解释接管和分流的区别，以及看不到连接时排错 | 2026-10-31本地与正式已发布 |
+| clash-routing-modes | mihomo-dns `#dns-2` | 出口正确但域名解析仍异常时继续查DNS | 2026-10-31本地与正式已发布 |
两篇Android教程通过订阅格式段落互链；Mac下载指南与操作教程互链，Linux从下载指南和真实Linux栏目获得入口，iOS沿用真实iOS栏目入口。系统代理与TUN专题由Windows和DNS正文提供入口，并指向三平台的基础操作及DNS专题。目录、标签、导航和热门榜不算正文关联；正文内链及锚点已经本地HTTP验证。
diff --git a/docs/content/tutorials/assets/clash-routing-modes/README.md b/docs/content/tutorials/assets/clash-routing-modes/README.md
new file mode 100644
index 00000000..f36d9f32
--- /dev/null
+++ b/docs/content/tutorials/assets/clash-routing-modes/README.md
@@ -0,0 +1,9 @@
+# 规则、全局与直连配图
+
+原生 SVG 为可编辑源，PNG 为文章 API 上传用图；未使用外部截图。封面沿用 system-proxy-tun-cover.svg 的现有样式；正文两图分别表达路由模式与代理组选择路径。
+
+- `cover.svg` / `cover.png`：960×540。
+- `modes.svg` / `modes.png`：1000×670。
+- `groups.svg` / `groups.png`：1000×610。
+
+正文源：../../clash-routing-modes.md。技术图使用本机 Chrome 在禁网页面渲染，正式展示副本通过文章资产 API 发布。制作/发布记录见 ../../../../maintenance/ROUTING_MODES_2026-10-31.md。
diff --git a/docs/content/tutorials/assets/clash-routing-modes/cover.png b/docs/content/tutorials/assets/clash-routing-modes/cover.png
new file mode 100644
index 00000000..27dd3922
Binary files /dev/null and b/docs/content/tutorials/assets/clash-routing-modes/cover.png differ
diff --git a/docs/content/tutorials/assets/clash-routing-modes/cover.svg b/docs/content/tutorials/assets/clash-routing-modes/cover.svg
new file mode 100644
index 00000000..c3cbc0a6
--- /dev/null
+++ b/docs/content/tutorials/assets/clash-routing-modes/cover.svg
@@ -0,0 +1 @@
+代理设置 · 综合教程 规则、全局与直连 分流模式 · 代理组 · 连接验证 同一条影音规则，两种不同的组内选择 情况一：影音组直接选择节点甲 影音规则 → 影音组 → 节点甲 调整“节点选择”不会改变上面这条选择路径。 情况二：影音组选择另一个代理组 影音规则 → 影音组 → 节点选择 → 节点乙 此时调整“节点选择”，才会影响影音连接的后续出口。 示意组名：请以自己的配置与新连接详情为准。 模式决定：已进入客户端的连接怎样出去 请求已进入 Mihomo 规则 → 匹配当前规则 → 代理组 / 直连 / 拒绝 全局 → 使用 GLOBAL 当前选择 → 选中的节点或策略 直连 → 使用本地网络 → 直接连接目标 未进入客户端的连接，不会仅因切换模式而被接管。 同一个网站，规则模式打不开，切成全局却正常；明明选了新节点，连接记录里还是另一个名字。遇到这类问题，先看这条连接实际走了哪条规则、哪个代理组，再决定要改什么。
本文以 Clash Verge Rev 和 Mihomo 为例，讲清规则、全局、直连三个模式，并完成一次“只让指定网站走指定出口”的配置。还没有完成导入和首次连接，可以先看 Windows 入门教程 ；Mac 用户可以从对应操作步骤 开始。
阅读路线 三个模式怎么选 为什么换节点没效果 规则先后顺序 添加一条网站规则 从连接记录验证 按现象排查 01 三个模式，改变的是出口选择 先确定前提：请求已经进入了客户端。系统代理、应用自身代理设置和 TUN 负责把流量送进来，下面三个模式负责决定进去以后怎样处理。未被接管的应用，不会因为切到全局就自动经过客户端；接管方式见系统代理与 TUN 的区别 。
模式 进入客户端后的普通业务连接 适合什么时候用 规则（Rule） 按当前配置匹配规则，选择直连、代理组或其他策略 日常分流：不同网站使用不同出口 全局（Global） 使用 GLOBAL 组当前选择的节点或策略 临时对比：判断问题是否与分流结果有关 直连（Direct） 由本地网络直接连接目标 临时检查本地网络，或不需要代理出口时
这三个模式是路由选择，不是速度档位。全局也要检查 GLOBAL 组究竟选了什么：如果选的是 DIRECT，结果仍然是直连；如果选的是另一个代理组，还要继续看那个组的选择。Mihomo 运行模式说明
直连模式也不等于退出客户端：系统代理、TUN 等入口可能仍开启。要停用接管，需要处理对应开关，不能只把模式改成“直连”。Clash Verge Rev 名词解释
图 1：模式作用于已进入客户端的连接；切模式不会补上接管范围的缺口。 02 换了节点没效果，可能换错了组 代理页里有“节点选择”“流媒体”“自动选择”等分组时，不要把它们当成一排作用相同的开关。规则通常先指向一个组，组再选节点，也可能继续选另一个组。
例如，一份配置把视频网站分给“影音”，普通网页交给“节点选择”。你在“节点选择”里换成节点乙，但“影音”仍直接选着节点甲，视频连接就可能继续走甲。只有“影音”选择了“节点选择”这个组，它才会沿着这条选择关系继续向下找出口。
图 2：两种配置的差别在于“影音”组的选择。组名只是配置中的名称，实际关系要查看当前选择。 手动选择组（select）由你决定使用哪个选项；如果它选择的是自动选择组（url-test），后者仍会按自己的测速配置选择节点。想固定到具体节点，就检查整条选择路径，而不是只看最外层的组名。手动选择组 与自动选择组
实际排查时，可以在连接详情里找策略、代理链或类似字段。不同界面展示顺序可能不同，重点是认出“命中了哪个组”和“最终使用哪个节点”。
03 先看顺序，再看规则写得对不对 Mihomo 的路由规则从上往下匹配。通常前面命中的规则就决定了后续策略，因此“更精确”不会自动获得更高优先级；精确规则如果排在已经覆盖它的规则之后，仍可能用不上。涉及 UDP 等条件时，还要注意目标策略是否具备相应支持。路由规则与优先级
下面是用来理解顺序的片段，不是可以替换整个订阅的完整配置。example.com 是示例域名，“节点选择”必须换成你配置中真实存在的组名：
rules:
- DOMAIN,video.example.com,节点选择
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,节点选择
在这个例子里，访问 video.example.com 先命中第一条，交给“节点选择”；访问 docs.example.com 则命中第二条，使用直连。如果把前两条交换，video.example.com 也会先被域名后缀规则接住。
DOMAIN 对应完整域名；DOMAIN-SUFFIX 对应该域名及其子域名。末尾的 MATCH 用于接住前面没有匹配到的连接。不要为了让某个网站使用节点，就在前面塞一条覆盖所有连接的 MATCH：那会让后面的分流规则失去机会。
04 在 Verge Rev 里给一个网站添加规则 先选一个你确实需要调整的网站。例如，某个域名在当前网络下直连不通，而你已有能访问它的节点。只改这一项，验证后再扩展范围。
在“订阅”页面找到正在使用的配置 ，右键选择“编辑规则”。这里维护的是该订阅的自定义规则，可以保留在后续订阅更新中。 新增规则，类型先选 DOMAIN，内容填写连接记录里的完整主机名，例如 video.example.com。不要填 https://、路径或整个网页地址。 代理策略选择当前配置中实际存在的代理组；需要直连时选 DIRECT，需要使用节点时选相应的组，并确认组内选择。 需要覆盖订阅中已有的分流结果时，放入前置规则 ，同时检查前面是否还有会先命中的自定义项。不要把它追加在已兜底的 MATCH 后面。 保存并确认没有配置错误，保持规则模式，然后让目标应用重新发起连接。 界面入口与前置/后置规则的含义可参考 Verge Rev 自定义规则 。这与直接改下载下来的订阅正文不同；后者可能被下一次更新覆盖。
一个网页可能同时访问登录、图片、视频和接口等多个域名。添加主站域名后页面只恢复了一部分，先查看失败连接，再补真正需要的域名。不要因为一个资源加载失败，就直接扩大成整类域名、全部应用或全部流量。
05 改完以后，检查一条新连接 验证时保持订阅、模式和接管方式稳定，只调整刚才那条规则或对应组的选择。打开“连接”页面，清除筛选，重新访问目标内容，找到刚建立的连接，逐项检查：
目标是否相同： 看实际域名或 IP，而不是只认浏览器标签页上的网站名。规则是否符合预期： 有没有命中新加的规则，还是先被另一条规则或规则集处理。策略是否正确： 命中的组是否是你刚才修改的组，组内有没有继续指向其他组或 DIRECT。应用是否恢复： 出口符合预期以后，再验证原先失败的操作，例如播放、登录或下载。已有长连接不适合作为换规则、换节点后的唯一观察对象。可优先重连目标应用，或只关闭相关连接后重新测试；直接清空所有连接会影响其他正在使用的程序。
如果仍无法区分，可以做一次有控制的对比：记录当前设置，在全局模式中选择同一个明确的节点 ，重新建立目标连接。全局可用、规则模式不可用，提示你继续查分流和代理组；它并不能单独证明某一条规则错误，因为模式变化也可能影响其他配置行为。对比后切回规则模式，修正具体目标。
06 几种常见现象，对应查哪里 现象 下一步检查 换了节点，目标连接仍走旧节点 是否改错代理组、组里还有嵌套选择，以及观察的是否为旧连接 明明加了代理规则，却显示 DIRECT 当前模式、规则顺序、实际域名，以及命中组是否选了 DIRECT 全局能用，规则不能用 对比同一目标的新连接，确认规则模式的最终出口是否与全局相同 网页文字出现了，图片或视频失败 找失败资源的域名与连接，逐项判断，不只给主站加规则 完全找不到应用的连接记录 清除筛选、查看日志，再检查应用代理或 TUN 接管；规则还没到发挥作用的阶段 订阅更新后又不对了 是否改了会被覆盖的订阅正文、当前配置是否切换、原代理组是否还存在
如果连接已经走了预期节点，但仍出现域名解析异常，继续检查 DNS 接管、加密和出口 。如果客户端根本看不到目标流量，则回到系统代理与 TUN 的排查步骤 。先根据连接记录确定问题发生在哪一步，再动对应设置，通常比不断切换三个模式更有效。
阅读路线 三个模式怎么选 为什么换节点没效果 规则先后顺序 添加一条网站规则 从连接记录验证 按现象排查 01 三个模式，改变的是出口选择
+
+先确定前提：请求已经进入了客户端。系统代理、应用自身代理设置和 TUN 负责把流量送进来，下面三个模式负责决定进去以后怎样处理。未被接管的应用，不会因为切到全局就自动经过客户端；接管方式见[系统代理与 TUN 的区别](/a/system-proxy-vs-tun.html#routing)。
+
+
+
+| 模式 | 进入客户端后的普通业务连接 | 适合什么时候用 |
+| --- | --- | --- |
+| 规则（Rule） | 按当前配置匹配规则，选择直连、代理组或其他策略 | 日常分流：不同网站使用不同出口 |
+| 全局（Global） | 使用 GLOBAL 组当前选择的节点或策略 | 临时对比：判断问题是否与分流结果有关 |
+| 直连（Direct） | 由本地网络直接连接目标 | 临时检查本地网络，或不需要代理出口时 |
+
+
+
+这三个模式是路由选择，不是速度档位。全局也要检查 GLOBAL 组究竟选了什么：如果选的是 DIRECT，结果仍然是直连；如果选的是另一个代理组，还要继续看那个组的选择。[Mihomo 运行模式说明](https://wiki.metacubex.one/config/general/)
+
+直连模式也不等于退出客户端：系统代理、TUN 等入口可能仍开启。要停用接管，需要处理对应开关，不能只把模式改成“直连”。[Clash Verge Rev 名词解释](https://www.clashverge.dev/guide/term.html)
+
+图 1：模式作用于已进入客户端的连接；切模式不会补上接管范围的缺口。 02 换了节点没效果，可能换错了组
+
+代理页里有“节点选择”“流媒体”“自动选择”等分组时，不要把它们当成一排作用相同的开关。规则通常先指向一个组，组再选节点，也可能继续选另一个组。
+
+例如，一份配置把视频网站分给“影音”，普通网页交给“节点选择”。你在“节点选择”里换成节点乙，但“影音”仍直接选着节点甲，视频连接就可能继续走甲。只有“影音”选择了“节点选择”这个组，它才会沿着这条选择关系继续向下找出口。
+
+图 2：两种配置的差别在于“影音”组的选择。组名只是配置中的名称，实际关系要查看当前选择。 03 先看顺序，再看规则写得对不对
+
+Mihomo 的路由规则从上往下匹配。通常前面命中的规则就决定了后续策略，因此“更精确”不会自动获得更高优先级；精确规则如果排在已经覆盖它的规则之后，仍可能用不上。涉及 UDP 等条件时，还要注意目标策略是否具备相应支持。[路由规则与优先级](https://wiki.metacubex.one/config/rules/)
+
+下面是用来理解顺序的片段，不是可以替换整个订阅的完整配置。`example.com` 是示例域名，“节点选择”必须换成你配置中真实存在的组名：
+
+```yaml
+rules:
+ - DOMAIN,video.example.com,节点选择
+ - DOMAIN-SUFFIX,example.com,DIRECT
+ - MATCH,节点选择
+```
+
+在这个例子里，访问 `video.example.com` 先命中第一条，交给“节点选择”；访问 `docs.example.com` 则命中第二条，使用直连。如果把前两条交换，`video.example.com` 也会先被域名后缀规则接住。
+
+`DOMAIN` 对应完整域名；`DOMAIN-SUFFIX` 对应该域名及其子域名。末尾的 `MATCH` 用于接住前面没有匹配到的连接。不要为了让某个网站使用节点，就在前面塞一条覆盖所有连接的 MATCH：那会让后面的分流规则失去机会。
+
+04 在 Verge Rev 里给一个网站添加规则
+
+先选一个你确实需要调整的网站。例如，某个域名在当前网络下直连不通，而你已有能访问它的节点。只改这一项，验证后再扩展范围。
+
+1. 在“订阅”页面找到**正在使用的配置**，右键选择“编辑规则”。这里维护的是该订阅的自定义规则，可以保留在后续订阅更新中。
+2. 新增规则，类型先选 `DOMAIN`，内容填写连接记录里的完整主机名，例如 `video.example.com`。不要填 `https://`、路径或整个网页地址。
+3. 代理策略选择当前配置中实际存在的代理组；需要直连时选 DIRECT，需要使用节点时选相应的组，并确认组内选择。
+4. 需要覆盖订阅中已有的分流结果时，放入**前置规则**，同时检查前面是否还有会先命中的自定义项。不要把它追加在已兜底的 MATCH 后面。
+5. 保存并确认没有配置错误，保持规则模式，然后让目标应用重新发起连接。
+
+界面入口与前置/后置规则的含义可参考 [Verge Rev 自定义规则](https://www.clashverge.dev/guide/rules.html)。这与直接改下载下来的订阅正文不同；后者可能被下一次更新覆盖。
+
+一个网页可能同时访问登录、图片、视频和接口等多个域名。添加主站域名后页面只恢复了一部分，先查看失败连接，再补真正需要的域名。不要因为一个资源加载失败，就直接扩大成整类域名、全部应用或全部流量。
+
+05 改完以后，检查一条新连接
+
+验证时保持订阅、模式和接管方式稳定，只调整刚才那条规则或对应组的选择。打开“连接”页面，清除筛选，重新访问目标内容，找到刚建立的连接，逐项检查：
+
+- **目标是否相同：** 看实际域名或 IP，而不是只认浏览器标签页上的网站名。
+- **规则是否符合预期：** 有没有命中新加的规则，还是先被另一条规则或规则集处理。
+- **策略是否正确：** 命中的组是否是你刚才修改的组，组内有没有继续指向其他组或 DIRECT。
+- **应用是否恢复：** 出口符合预期以后，再验证原先失败的操作，例如播放、登录或下载。
+
+已有长连接不适合作为换规则、换节点后的唯一观察对象。可优先重连目标应用，或只关闭相关连接后重新测试；直接清空所有连接会影响其他正在使用的程序。
+
+如果仍无法区分，可以做一次有控制的对比：记录当前设置，在全局模式中选择**同一个明确的节点**，重新建立目标连接。全局可用、规则模式不可用，提示你继续查分流和代理组；它并不能单独证明某一条规则错误，因为模式变化也可能影响其他配置行为。对比后切回规则模式，修正具体目标。
+
+06 几种常见现象，对应查哪里
+
+
+
+| 现象 | 下一步检查 |
+| --- | --- |
+| 换了节点，目标连接仍走旧节点 | 是否改错代理组、组里还有嵌套选择，以及观察的是否为旧连接 |
+| 明明加了代理规则，却显示 DIRECT | 当前模式、规则顺序、实际域名，以及命中组是否选了 DIRECT |
+| 全局能用，规则不能用 | 对比同一目标的新连接，确认规则模式的最终出口是否与全局相同 |
+| 网页文字出现了，图片或视频失败 | 找失败资源的域名与连接，逐项判断，不只给主站加规则 |
+| 完全找不到应用的连接记录 | 清除筛选、查看日志，再检查应用代理或 TUN 接管；规则还没到发挥作用的阶段 |
+| 订阅更新后又不对了 | 是否改了会被覆盖的订阅正文、当前配置是否切换、原代理组是否还存在 |
+
+
+
+如果连接已经走了预期节点，但仍出现域名解析异常，继续检查 [DNS 接管、加密和出口](/a/mihomo-dns-leak.html#dns-2)。如果客户端根本看不到目标流量，则回到[系统代理与 TUN 的排查步骤](/a/system-proxy-vs-tun.html#troubleshoot)。先根据连接记录确定问题发生在哪一步，再动对应设置，通常比不断切换三个模式更有效。
diff --git a/docs/content/tutorials/system-proxy-tun.html b/docs/content/tutorials/system-proxy-tun.html
index fab97049..7295c15b 100644
--- a/docs/content/tutorials/system-proxy-tun.html
+++ b/docs/content/tutorials/system-proxy-tun.html
@@ -1 +1 @@
-浏览器能打开网页，终端却一直超时；已经切到“全局”，游戏还是连不上；打开 TUN 后能用了，又担心所有网站都被送到国外。遇到这些情况，先分清两件事：流量有没有进入代理客户端，以及进入以后走哪个出口。
系统代理和 TUN 主要解决第一件事，规则、全局和直连模式主要解决第二件事。本文以 Clash Verge Rev 和 Mihomo 桌面客户端为例，说明它们的区别、适用场景和检查方法。
阅读路线 系统代理接管什么 TUN 改变了什么 为什么全局不等于全部 应该用哪一种 怎样切换和检查 按现象排错 DNS 还要单独看 01 系统代理：让应用按设置转交请求 打开 Clash Verge Rev 的“系统代理”，客户端会修改操作系统的代理设置，把代理地址指向本机正在监听的端口。愿意读取并遵循这项设置的应用，就会把相应请求交给客户端处理。浏览器通常可以通过这种方式使用代理。官方快速入门
这里的关键是“应用遵循设置”。有的软件读取系统设置，有的软件使用自己的代理配置，还有的软件直接建立连接。同一台电脑上，浏览器正常、另一个应用不走代理，并不矛盾。
图 1 · 系统代理依赖应用配合
应用读取设置 使用系统指定的代理
→ 本机代理端口 请求进入 Mihomo
→ 匹配出口 直连或代理节点
不遵循系统代理的应用：仍按自己的网络设置连接，不会仅因这个开关而进入 Mihomo。
这也解释了为什么“浏览器能用”不能代表电脑上每个应用都已经走代理。 如果应用提供 HTTP 或 SOCKS 代理选项，可以单独指向客户端的本机端口。地址通常是 127.0.0.1，端口应查看客户端当前设置，不要照抄别人的数字；HTTP、SOCKS 和混合端口也要对应正确。
终端工具同样需要看各自支持什么。以 Linux 上的 curl 为例，可以先用单条命令指定代理的方法 检查，不必为了一个工具马上接管整台电脑。
02 TUN：通过虚拟网卡接收流量 TUN 会创建虚拟网络接口，并通过路由把符合接管条件的 IP 流量交给内核。应用不必先学会使用 HTTP 或 SOCKS 代理，因此它常用于系统代理无法覆盖的程序。Mihomo 可以处理通过 TUN 进入的 TCP、UDP 流量，但最终能否完成连接，还取决于配置、节点和目标服务。官方名词解释
图 2 · TUN 在网络路由这一层接管
应用发起连接 无需读取系统代理
→ 系统路由 → TUN 进入虚拟网卡
→ Mihomo 处理 再决定实际出口
被排除的地址、接口或其他未进入 TUN 的连接，仍可能走原来的网络路径。
TUN 扩大了接管范围，但开关亮着不等于每一条连接都已被接管。 TUN 也有接管范围。自动路由、排除网段、IPv6 设置及其他 VPN 的路由，都可能影响实际路径。例如，把某个局域网网段排除在 TUN 之外，就是让它绕过这层接管；这与连接进入 Mihomo 后命中 DIRECT 规则不同。Mihomo TUN 配置 、代理绕过说明
日常使用图形客户端时，优先使用它提供的 TUN 设置。建立网卡和修改路由需要相应权限；Clash Verge Rev 的服务模式可让具有权限的后台服务启动内核，不代表必须一直以管理员身份运行整个界面。服务模式说明
03 “全局”和 TUN 不是同一个维度 把“规则”改成“全局”，改变的是进入内核后的出口选择。一个完全没有进入客户端的应用，不会因为切到全局就自动被接管。
反过来，开启 TUN 也不要求使用全局模式。TUN + 规则模式 可以接管更多应用，同时继续按规则让部分连接直连、部分连接使用节点。规则与全局模式说明
图 3 · 先进入客户端，再决定去哪里
第一步：接管 系统代理 / 应用代理 / TUN
→ 第二步：选择出口 规则 / 全局 / 直连
→ 第三步：建立连接 本地网络或所选节点
排错也按这个顺序进行：先找有没有进入，再看实际出口，最后判断线路是否可用。 常见组合 实际含义 系统代理 + 规则 遵循系统代理的请求进入客户端，再按当前配置分流 系统代理 + 全局 进入内核的普通业务连接使用全局策略；未被接管的应用仍可能绕过 TUN + 规则 被 TUN 接管的连接按规则选择出口，并非全部使用代理节点 TUN + 全局 被接管的普通业务连接使用全局策略；仍需查看所选策略是否为可用节点
一个具体例子：浏览器和下载工具访问同一域名，浏览器连接记录里显示了节点，下载工具却没有记录。此时应优先检查下载工具的代理设置或接管方式；反复切换全局，通常没有解决前面的缺口。
04 按应用需求选择，不必一开始全部打开 你要完成的事 可以先这样做 主要浏览网页，常用软件已经正常 使用系统代理 + 规则模式 只有一个应用不跟随系统设置，且自带代理选项 给该应用配置正确的本机代理端口 多个应用不支持代理设置，希望统一处理 考虑 TUN + 规则模式，再逐个检查所需应用 游戏或语音涉及 UDP 检查 TUN 接管，同时确认所选节点支持所需 UDP 转发 需要同时访问公司 VPN、NAS 或局域网设备 先明确这些连接的路径，再设置绕过或直连，避免盲目全局接管
TUN 不是加速档位。 游戏登录网页能打开，不代表游戏数据传输已经正常；节点对网页可用，也不代表它能承载所需的 UDP。选择方式要看应用连接是否按预期工作，而不是哪个开关听起来更强。
系统代理和 TUN 可以同时存在，但两个开关都开不代表效果翻倍。应用主动交给本机端口的请求，本来就已进入客户端；其他连接可能由 TUN 接管。排错时，先明确正在验证哪条路径，比同时改动多个设置更容易找到原因。
05 从系统代理切到 TUN，怎样确认有效 先确保客户端已经导入配置、选中可用节点，并完成基本连接。尚未完成这一步，可以按对应平台的教程操作：Windows 、Mac 、Linux 。
记录原来的设置。 包括系统代理、TUN 开关和当前代理组。保持订阅、节点和规则模式不变，便于对比。按客户端提示启用服务和 TUN。 若开关自动关闭或提示权限错误，先处理服务状态与具体错误，不要继续叠加 DNS、协议栈等改动。排除其他入口的干扰。 若要确认某个应用是否由 TUN 接管，暂时关闭本客户端的系统代理，并检查该应用是否另设了代理；有的话记录原值，再临时停用。只关闭系统代理，不能排除应用自己的代理设置。让目标应用发起新连接。 重连应用或重新打开目标内容，避免只观察缓存页面和原有长连接。查看连接记录。 按域名、目标 IP 或可用的进程信息定位请求，查看匹配规则、出口策略，以及界面或日志提供的入站信息。应走节点的请求如果显示 DIRECT，需要回到分流规则检查。检查日常需要的本地服务。 包括局域网设备、公司内网等；确认没有因路由变化失去访问能力，再保留这套设置。关掉系统代理后应用仍能联网，只能说明它不依赖刚才关闭的那项设置。还要结合新连接记录和实际出口，才能判断 TUN 是否按预期接管；应用本来就能直连时，单凭“能打开”尤其容易误判。
如果切换后异常，先关闭 TUN，恢复刚才记录的系统代理和应用设置，让连接回到原先可用的状态，再按下一节定位。
06 按现象定位，少做无关改动 浏览器能用，终端或另一个应用不能用 先检查该应用是否跟随系统代理，或者是否需要独立配置。观察它发起新请求时，客户端有没有相应连接记录。记录里没有出现时，先清除列表筛选、重试并查看日志，排查接管问题；已经出现时，再看命中的规则和实际出口。
开了 TUN，流量仍显示 DIRECT DIRECT 表示这条连接由客户端直连，并不等于 TUN 没有工作。检查它是否命中了局域网、国内地址等直连规则，或代理组本身选中了 DIRECT。需要改变的是对应出口策略，而不是反复重启虚拟网卡。
网页正常，游戏或语音仍然失败 把登录请求和实时数据连接分开看。后者可能使用不同的地址、端口和 UDP。确认目标连接已进入客户端，再检查节点是否支持相关转发；网页测试成功不能代替这项检查。
一开 TUN，局域网、公司 VPN 或整个网络就异常 先恢复原先可用的方式，再检查路由重叠、网段冲突和客户端日志。系统代理绕过、TUN 路由排除与内核 DIRECT 规则各自发生在不同位置，不应混为一谈。不要把删除网卡或关闭全部防火墙作为第一步。代理绕过说明 、Windows TUN 常见问题
关闭系统代理，连接却还在走节点 检查 TUN 是否仍开启，以及应用自己的代理设置是否仍生效。想停用本客户端的接管，应同时处理实际启用的入口，并重新建立连接。关闭窗口可能只是把客户端收进托盘，也不等于退出。
07 TUN 能接管流量，DNS 仍要单独检查 访问网站的连接和解析域名的查询，可能走不同路径。TUN 已经开启，并不能直接推出“DNS 一定经过节点”。普通 DNS 是否被接管、应用是否使用独立的加密 DNS，以及解析服务连接走直连还是代理，都需要分别看。
例如，浏览器使用 DoH 时，查询本身是加密的 HTTPS 连接。它可能经 TUN 进入内核，但不会仅因一条针对 53 端口的 DNS 劫持设置，就自动变成 Mihomo 内置 DNS 处理的查询。相关字段和平台差异见Mihomo TUN 配置 。
想继续检查解析路径，可以阅读DNS 防泄漏配置与验证 。日常排查时，先确认应用连接进入了哪里，再看它选了什么出口，最后补上 DNS 这条路径，通常比不断切换“系统代理、TUN、全局”更有效。
浏览器能打开网页，终端却一直超时；已经切到“全局”，游戏还是连不上；打开 TUN 后能用了，又担心所有网站都被送到国外。遇到这些情况，先分清两件事：流量有没有进入代理客户端，以及进入以后走哪个出口。
系统代理和 TUN 主要解决第一件事，规则、全局和直连模式主要解决第二件事。本文以 Clash Verge Rev 和 Mihomo 桌面客户端为例，说明它们的区别、适用场景和检查方法。
阅读路线 系统代理接管什么 TUN 改变了什么 为什么全局不等于全部 应该用哪一种 怎样切换和检查 按现象排错 DNS 还要单独看 01 系统代理：让应用按设置转交请求 打开 Clash Verge Rev 的“系统代理”，客户端会修改操作系统的代理设置，把代理地址指向本机正在监听的端口。愿意读取并遵循这项设置的应用，就会把相应请求交给客户端处理。浏览器通常可以通过这种方式使用代理。官方快速入门
这里的关键是“应用遵循设置”。有的软件读取系统设置，有的软件使用自己的代理配置，还有的软件直接建立连接。同一台电脑上，浏览器正常、另一个应用不走代理，并不矛盾。
图 1 · 系统代理依赖应用配合
应用读取设置 使用系统指定的代理
→ 本机代理端口 请求进入 Mihomo
→ 匹配出口 直连或代理节点
不遵循系统代理的应用：仍按自己的网络设置连接，不会仅因这个开关而进入 Mihomo。
这也解释了为什么“浏览器能用”不能代表电脑上每个应用都已经走代理。 如果应用提供 HTTP 或 SOCKS 代理选项，可以单独指向客户端的本机端口。地址通常是 127.0.0.1，端口应查看客户端当前设置，不要照抄别人的数字；HTTP、SOCKS 和混合端口也要对应正确。
终端工具同样需要看各自支持什么。以 Linux 上的 curl 为例，可以先用单条命令指定代理的方法 检查，不必为了一个工具马上接管整台电脑。
02 TUN：通过虚拟网卡接收流量 TUN 会创建虚拟网络接口，并通过路由把符合接管条件的 IP 流量交给内核。应用不必先学会使用 HTTP 或 SOCKS 代理，因此它常用于系统代理无法覆盖的程序。Mihomo 可以处理通过 TUN 进入的 TCP、UDP 流量，但最终能否完成连接，还取决于配置、节点和目标服务。官方名词解释
图 2 · TUN 在网络路由这一层接管
应用发起连接 无需读取系统代理
→ 系统路由 → TUN 进入虚拟网卡
→ Mihomo 处理 再决定实际出口
被排除的地址、接口或其他未进入 TUN 的连接，仍可能走原来的网络路径。
TUN 扩大了接管范围，但开关亮着不等于每一条连接都已被接管。 TUN 也有接管范围。自动路由、排除网段、IPv6 设置及其他 VPN 的路由，都可能影响实际路径。例如，把某个局域网网段排除在 TUN 之外，就是让它绕过这层接管；这与连接进入 Mihomo 后命中 DIRECT 规则不同。Mihomo TUN 配置 、代理绕过说明
日常使用图形客户端时，优先使用它提供的 TUN 设置。建立网卡和修改路由需要相应权限；Clash Verge Rev 的服务模式可让具有权限的后台服务启动内核，不代表必须一直以管理员身份运行整个界面。服务模式说明
03 “全局”和 TUN 不是同一个维度 把“规则”改成“全局”，改变的是进入内核后的出口选择。一个完全没有进入客户端的应用，不会因为切到全局就自动被接管。
反过来，开启 TUN 也不要求使用全局模式。TUN + 规则模式 可以接管更多应用，同时继续按规则让部分连接直连、部分连接使用节点。规则与全局模式说明
图 3 · 先进入客户端，再决定去哪里
第一步：接管 系统代理 / 应用代理 / TUN
→ 第二步：选择出口 规则 / 全局 / 直连
→ 第三步：建立连接 本地网络或所选节点
排错也按这个顺序进行：先找有没有进入，再看实际出口，最后判断线路是否可用。 常见组合 实际含义 系统代理 + 规则 遵循系统代理的请求进入客户端，再按当前配置分流 系统代理 + 全局 进入内核的普通业务连接使用全局策略；未被接管的应用仍可能绕过 TUN + 规则 被 TUN 接管的连接按规则选择出口，并非全部使用代理节点 TUN + 全局 被接管的普通业务连接使用全局策略；仍需查看所选策略是否为可用节点
一个具体例子：浏览器和下载工具访问同一域名，浏览器连接记录里显示了节点，下载工具却没有记录。此时应优先检查下载工具的代理设置或接管方式；反复切换全局，通常没有解决前面的缺口。
如果流量已经进入客户端，却仍走错节点，可以继续看规则模式、代理组与实际出口的检查方法 ，分清应该改哪一个组。
04 按应用需求选择，不必一开始全部打开 你要完成的事 可以先这样做 主要浏览网页，常用软件已经正常 使用系统代理 + 规则模式 只有一个应用不跟随系统设置，且自带代理选项 给该应用配置正确的本机代理端口 多个应用不支持代理设置，希望统一处理 考虑 TUN + 规则模式，再逐个检查所需应用 游戏或语音涉及 UDP 检查 TUN 接管，同时确认所选节点支持所需 UDP 转发 需要同时访问公司 VPN、NAS 或局域网设备 先明确这些连接的路径，再设置绕过或直连，避免盲目全局接管
TUN 不是加速档位。 游戏登录网页能打开，不代表游戏数据传输已经正常；节点对网页可用，也不代表它能承载所需的 UDP。选择方式要看应用连接是否按预期工作，而不是哪个开关听起来更强。
系统代理和 TUN 可以同时存在，但两个开关都开不代表效果翻倍。应用主动交给本机端口的请求，本来就已进入客户端；其他连接可能由 TUN 接管。排错时，先明确正在验证哪条路径，比同时改动多个设置更容易找到原因。
05 从系统代理切到 TUN，怎样确认有效 先确保客户端已经导入配置、选中可用节点，并完成基本连接。尚未完成这一步，可以按对应平台的教程操作：Windows 、Mac 、Linux 。
记录原来的设置。 包括系统代理、TUN 开关和当前代理组。保持订阅、节点和规则模式不变，便于对比。按客户端提示启用服务和 TUN。 若开关自动关闭或提示权限错误，先处理服务状态与具体错误，不要继续叠加 DNS、协议栈等改动。排除其他入口的干扰。 若要确认某个应用是否由 TUN 接管，暂时关闭本客户端的系统代理，并检查该应用是否另设了代理；有的话记录原值，再临时停用。只关闭系统代理，不能排除应用自己的代理设置。让目标应用发起新连接。 重连应用或重新打开目标内容，避免只观察缓存页面和原有长连接。查看连接记录。 按域名、目标 IP 或可用的进程信息定位请求，查看匹配规则、出口策略，以及界面或日志提供的入站信息。应走节点的请求如果显示 DIRECT，需要回到分流规则检查。检查日常需要的本地服务。 包括局域网设备、公司内网等；确认没有因路由变化失去访问能力，再保留这套设置。关掉系统代理后应用仍能联网，只能说明它不依赖刚才关闭的那项设置。还要结合新连接记录和实际出口，才能判断 TUN 是否按预期接管；应用本来就能直连时，单凭“能打开”尤其容易误判。
如果切换后异常，先关闭 TUN，恢复刚才记录的系统代理和应用设置，让连接回到原先可用的状态，再按下一节定位。
06 按现象定位，少做无关改动 浏览器能用，终端或另一个应用不能用 先检查该应用是否跟随系统代理，或者是否需要独立配置。观察它发起新请求时，客户端有没有相应连接记录。记录里没有出现时，先清除列表筛选、重试并查看日志，排查接管问题；已经出现时，再看命中的规则和实际出口。
开了 TUN，流量仍显示 DIRECT DIRECT 表示这条连接由客户端直连，并不等于 TUN 没有工作。检查它是否命中了局域网、国内地址等直连规则，或代理组本身选中了 DIRECT。需要改变的是对应出口策略，而不是反复重启虚拟网卡。
网页正常，游戏或语音仍然失败 把登录请求和实时数据连接分开看。后者可能使用不同的地址、端口和 UDP。确认目标连接已进入客户端，再检查节点是否支持相关转发；网页测试成功不能代替这项检查。
一开 TUN，局域网、公司 VPN 或整个网络就异常 先恢复原先可用的方式，再检查路由重叠、网段冲突和客户端日志。系统代理绕过、TUN 路由排除与内核 DIRECT 规则各自发生在不同位置，不应混为一谈。不要把删除网卡或关闭全部防火墙作为第一步。代理绕过说明 、Windows TUN 常见问题
关闭系统代理，连接却还在走节点 检查 TUN 是否仍开启，以及应用自己的代理设置是否仍生效。想停用本客户端的接管，应同时处理实际启用的入口，并重新建立连接。关闭窗口可能只是把客户端收进托盘，也不等于退出。
07 TUN 能接管流量，DNS 仍要单独检查 访问网站的连接和解析域名的查询，可能走不同路径。TUN 已经开启，并不能直接推出“DNS 一定经过节点”。普通 DNS 是否被接管、应用是否使用独立的加密 DNS，以及解析服务连接走直连还是代理，都需要分别看。
例如，浏览器使用 DoH 时，查询本身是加密的 HTTPS 连接。它可能经 TUN 进入内核，但不会仅因一条针对 53 端口的 DNS 劫持设置，就自动变成 Mihomo 内置 DNS 处理的查询。相关字段和平台差异见Mihomo TUN 配置 。
想继续检查解析路径，可以阅读DNS 防泄漏配置与验证 。日常排查时，先确认应用连接进入了哪里，再看它选了什么出口，最后补上 DNS 这条路径，通常比不断切换“系统代理、TUN、全局”更有效。
04 按应用需求选择，不必一开始全部打开
| 你要完成的事 | 可以先这样做 |
diff --git a/docs/maintenance/EDITORIAL_RELEASE.md b/docs/maintenance/EDITORIAL_RELEASE.md
index 85c661d9..c936d87a 100644
--- a/docs/maintenance/EDITORIAL_RELEASE.md
+++ b/docs/maintenance/EDITORIAL_RELEASE.md
@@ -45,3 +45,7 @@ ## 状态与恢复
IndexNow的结果、环境开关及服务器延时重试见[教程SEO通知](EDITORIAL_INDEXNOW.md)。通知pending只重试后处理，不再次发表正文。
2026-10-31编辑发布已接入[IndexNow通知与重试](EDITORIAL_INDEXNOW.md)，复用发布回执effects；通知pending不表示正文未发布，禁止为通知重发正文。
+
+## 图片发布目录
+
+2026-10-31首篇真实上传配图时发现正式 `public/images/editorial` 缺失。用户明确批准创建该专用目录并设为nginx所有、0755；已实施并完成真实文章发布。上级public/images权限未改变。以后部署预检该目录存在且执行身份nginx可写，禁止临时以root执行文章发布来绕过。回执见[首篇周期教程](ROUTING_MODES_2026-10-31.md)。
diff --git a/docs/maintenance/ROUTING_MODES_2026-10-31.json b/docs/maintenance/ROUTING_MODES_2026-10-31.json
new file mode 100644
index 00000000..2cecd78f
--- /dev/null
+++ b/docs/maintenance/ROUTING_MODES_2026-10-31.json
@@ -0,0 +1,173 @@
+{
+ "release_id": "daabedf9-a81c-49ca-995b-7b6832dd2254",
+ "published_at": "2026-10-31T06:58:28+00:00",
+ "phase": "complete",
+ "receipt": {
+ "publication_id": "c7f9be21-3914-43f1-b7e5-9e7b49ef224d",
+ "status": "published",
+ "articles": [
+ {
+ "content_key": "clash-routing-modes",
+ "article_id": 382,
+ "revision": 1,
+ "content_changed": true,
+ "url": "https://clashfreenode.com/a/clash-rule-global-direct.html"
+ },
+ {
+ "content_key": "system-proxy-vs-tun",
+ "article_id": 376,
+ "revision": 2,
+ "content_changed": true,
+ "url": "https://clashfreenode.com/a/system-proxy-vs-tun.html"
+ }
+ ],
+ "effects": {
+ "indexnow": {
+ "status": "done",
+ "attempts": 1,
+ "http_status": 200,
+ "urls": [
+ "https://clashfreenode.com/a/clash-rule-global-direct.html",
+ "https://clashfreenode.com/a/system-proxy-vs-tun.html"
+ ],
+ "submitted_at": "2026-10-31T06:58:29+00:00",
+ "result": "received"
+ },
+ "cache": {
+ "status": "done"
+ },
+ "search": {
+ "status": "done",
+ "method": "meilisearch",
+ "index": "cfn_articles_v3",
+ "documents": 2
+ },
+ "sitemap": {
+ "status": "done",
+ "method": "database-driven"
+ }
+ }
+ },
+ "readback": [
+ {
+ "content_key": "clash-routing-modes",
+ "article_id": 382,
+ "revision_matches": true,
+ "content_matches": true,
+ "body_sha256": "b9986ade5893115611f8a02070f5e98ba2fb8b7d9a100dff39e11ff60876c5c2",
+ "like_growth": {
+ "seven_day_remaining": 29,
+ "yearly": 50,
+ "one_year_target": 241,
+ "one_year_added": 0,
+ "one_year_started_at": "2026-10-31 06:58:28"
+ }
+ },
+ {
+ "content_key": "system-proxy-vs-tun",
+ "article_id": 376,
+ "revision_matches": true,
+ "content_matches": true,
+ "body_sha256": "255db797e5e1403ee779e960e2129558e160badf0fe53f1822250b8d45e0ddb3",
+ "like_growth": {
+ "seven_day_remaining": 0,
+ "yearly": 50,
+ "one_year_target": 106,
+ "one_year_added": 0,
+ "one_year_started_at": "2026-10-29 13:30:35"
+ }
+ }
+ ],
+ "display_published_at_utc": "2026-10-31 02:10:28",
+ "http": {
+ "new_page": 200,
+ "chapter_anchors": [
+ "custom",
+ "groups",
+ "modes",
+ "order",
+ "troubleshoot",
+ "verify"
+ ],
+ "images": [
+ {
+ "path": "/images/editorial/417b203a4af30200b6ed3b37d0b0e823a9b47db49e2d743b1110b35329cc5de8.png",
+ "status": 200,
+ "sha256_matches": true
+ },
+ {
+ "path": "/images/editorial/98a43bdd771dd4c6c5ec6b87bb5f0ebf679fa2b228dddbb764adecf50b0374e9.png",
+ "status": 200,
+ "sha256_matches": true
+ }
+ ],
+ "links": [
+ {
+ "target": "/a/clash-verge-rev-windows.html#enable",
+ "status": 200,
+ "anchor_exists": true
+ },
+ {
+ "target": "/a/m173.html#enable",
+ "status": 200,
+ "anchor_exists": true
+ },
+ {
+ "target": "/a/mihomo-dns-leak.html#dns-2",
+ "status": 200,
+ "anchor_exists": true
+ },
+ {
+ "target": "/a/system-proxy-vs-tun.html#routing",
+ "status": 200,
+ "anchor_exists": true
+ },
+ {
+ "target": "/a/system-proxy-vs-tun.html#troubleshoot",
+ "status": 200,
+ "anchor_exists": true
+ }
+ ],
+ "incoming_link": true,
+ "directory": {
+ "owner": "nginx",
+ "mode": "0o755"
+ },
+ "head": "77f9b09c58b46ef2bbe0882ec89194bf25aa82cd"
+ },
+ "local_browser": {
+ "checks": [
+ {
+ "width": 1360,
+ "scroll": 1360,
+ "headings": [
+ "01 三个模式，改变的是出口选择",
+ "02 换了节点没效果，可能换错了组",
+ "03 先看顺序，再看规则写得对不对",
+ "04 在 Verge Rev 里给一个网站添加规则",
+ "05 改完以后，检查一条新连接",
+ "06 几种常见现象，对应查哪里"
+ ],
+ "brokenImages": [],
+ "tables": 2,
+ "images": 2
+ },
+ {
+ "width": 390,
+ "scroll": 390,
+ "headings": [
+ "01 三个模式，改变的是出口选择",
+ "02 换了节点没效果，可能换错了组",
+ "03 先看顺序，再看规则写得对不对",
+ "04 在 Verge Rev 里给一个网站添加规则",
+ "05 改完以后，检查一条新连接",
+ "06 几种常见现象，对应查哪里"
+ ],
+ "brokenImages": [],
+ "tables": 2,
+ "images": 2
+ }
+ ],
+ "blockedOrigins": []
+ }
+}
diff --git a/docs/maintenance/ROUTING_MODES_2026-10-31.md b/docs/maintenance/ROUTING_MODES_2026-10-31.md
new file mode 100644
index 00000000..ec7ddda6
--- /dev/null
+++ b/docs/maintenance/ROUTING_MODES_2026-10-31.md
@@ -0,0 +1,36 @@
+# 规则、全局与直连教程 · 2026-10-31
+
+## 本次授权与范围
+
+用户要求“现在就来一篇，当检测触发了”。本次作为提前的人工触发登记到2026-10-26周的 `2026-10-26-manual-1` 槽位，不改变2026-11-02起的每周三篇计划。本篇已按真实发布回执计入当周额度。
+
+新文内容键 `clash-routing-modes`，路径 `/a/clash-rule-global-direct.html`，栏目综合教程。两张解释图、一张沿用现有样式的封面。系统代理/TUN文章只在 `#choose` 前补一个新文 `#groups` 入口，其余内容不改。新文链接Windows入门 `#enable`、Mac入门 `#enable`、TUN `#routing` / `#troubleshoot`、DNS `#dns-2`。
+
+## 资料与质量检查
+
+2026-10-31阅读 Mihomo 官方运行模式、路由规则、手动/自动代理组文档，以及 Clash Verge Rev 名词解释、自定义规则文档。准确链接保留在正文。原创示例使用example.com，不把配置片段写成完整可直接导入的订阅。未开展客户端真机联网实测，此边界只留维护记录。
+
+本地实际模板桌面1360和手机390检查：均无横向溢出、2张正文图无破图、2张表格正常渲染、6个章节锚点存在。浏览器请求先按本地origin白名单拦截；没有本机线上页面访问。初次检查发现本地Vite未运行，启动原5187开发服务后复检通过，未改样式。正式签名预览由VPS-003内部Kernel渲染，未在本机打开其线上资源。
+
+## 发布与恢复
+
+- release_id：`daabedf9-a81c-49ca-995b-7b6832dd2254`
+- publication_request_id：`c7f9be21-3914-43f1-b7e5-9e7b49ef224d`
+- draft hash：`6ebc848487be507cd71e61016bf1232f1fc7c28b4042f019ff63654c8e29c486`
+- 正式冻结默认值：i7like 29，i365like 50，一次性年度目标241；显示偏移17280秒。旧文设置不变。
+- 本地已通过API发表：新文ID366/版本1，TUN ID365/版本2；本地IndexNow禁用并返回skipped。
+- 正式首次publish失败；原ID status确认尚无发表回执，草稿仍draft。VPS-003错误为ContentRenderer.php:83 mkdir Permission denied；公开图片目录 `public/images/editorial` 不存在，上级root:root0755，API运行身份nginx无法创建。私有资产上传目录nginx:nginx0700正常。
+- 创建该专用目录并设nginx:nginx0755的操作被自动审批拒绝（持久生产权限变更）；用户随后明确批准“允许，仅创建这个专用目录并继续发布”，已按该范围创建并验证；其他目录所有权与权限未改。沿原release恢复，未另起发布请求。
+- 私有工作文件：本机 `/private/tmp/fna-modes-20261031/`；服务器原release台账位于 `storage/app/private/editorial-releases/daabedf9-a81c-49ca-995b-7b6832dd2254.json`。
+
+## 最终验收
+
+正式发布完成：2026-10-31 14:58:28北京时间（服务器回执06:58:28 UTC），新文ID382/版本1，TUN ID376/版本2。展示时间比实际时间提前17280秒（4小时48分）；点赞29/50/241已回读，旧文106年度目标及起点保留。新文全文与冻结版、两文版本、三张上传图片文件SHA由发布封装回读一致。
+
+IndexNow由VPS-003在14:58:29北京时间提交新文和旧文更新两条URL，HTTP200、attempts1；白色机仅转发SSH。缓存、Meilisearch与sitemap均done，phase complete。此结果表示通知接收，不表示搜索引擎已收录。
+
+服务器侧真实HTTP：新文200，2张正文图200且SHA一致；5条正文关联链接200且锚点存在，TUN旧文入向链接存在，6个章节锚点齐全。目录nginx所有/0755回读通过。已完成服务器侧验收，未做线上页面验收。本机浏览器只验收本地实际模板。
+
+周期台账已用原release回执record到2026-10-26-manual-1，实际发表时间用于计数；2026-11-02当周三个计划未改。正文、图源、PNG、渲染HTML、关系索引同步保存，机器可读回执见[发布证据](ROUTING_MODES_2026-10-31.json)。
+
+如需回退，旧文可从API版本1创建回退草稿，新文保留同URL通过API修订；不直接SQL修改，也不为撤回图片删除共享内容寻址资源。专用图片目录是API后续发文必需部署项，新增部署前应检查该目录归属与nginx写入能力。
diff --git a/docs/maintenance/WEEKLY_TUTORIALS.md b/docs/maintenance/WEEKLY_TUTORIALS.md
index 5c90a199..9a0b981b 100644
--- a/docs/maintenance/WEEKLY_TUTORIALS.md
+++ b/docs/maintenance/WEEKLY_TUTORIALS.md
@@ -1,6 +1,6 @@
# 综合教程周期写作
-2026-10-31用户最终规则：每周三篇，每天北京时间15:00检查；文章展示时间随机往前0～6小时，精确到秒。原每周两篇、早晚两个窗口的规则已替换。Codex heartbeat `fna`，名称“FNA 综合教程｜每周三篇”，ACTIVE，绑定本聊天，自2026-11-02当周开始。调度已修改，首轮实际写作尚未执行。
+2026-10-31用户最终规则：每周三篇，每天北京时间15:00检查；文章展示时间随机往前0～6小时，精确到秒。原每周两篇、早晚两个窗口的规则已替换。Codex heartbeat `fna`，名称“FNA 综合教程｜每周三篇”，ACTIVE，绑定本聊天，自2026-11-02当周开始。调度已修改；2026-10-31用户提前手动触发一篇已正式发布并计入当周台账，2026-11-02当周的三次计划保持不变。详见[首篇记录](ROUTING_MODES_2026-10-31.md)。
## 执行入口
