diff --git a/docs/content/WRITING.md b/docs/content/WRITING.md index 0640e684..ebfe919e 100644 --- a/docs/content/WRITING.md +++ b/docs/content/WRITING.md @@ -109,7 +109,8 @@ ## 2 当前文章登记 | cfw-mac-legacy | 210 / 进阶教程 | Clash Verge Rev 使用教程：Mac 安装、订阅与系统代理 | `/a/m173.html` | [verge-mac.md](tutorials/verge-mac.md)；本地API版本3 | Mac操作入口；#install DMG安装，#import 订阅，系统代理与退出排错；无设备联网实测 | | cfw-linux-legacy | 211 / 进阶教程 | Clash Verge Rev 使用教程：Linux 安装、订阅与代理设置 | `/a/m174.html` | [verge-linux.md](tutorials/verge-linux.md)；本地API版本6 | 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` 验证新连接 | +| clash-routing-modes | 366 / 进阶教程 | Clash 规则、全局和直连怎么选？代理组与分流排错教程 | `/a/clash-rule-global-direct.html` | [clash-routing-modes.md](tutorials/clash-routing-modes.md)；2026-11-03本地ID366/版本2，正式ID382/版本2已发布（补测速入口） | 模式选择与代理组分流；`#groups` 组内选择、`#custom` 添加规则、`#verify` 验证新连接 | +| clash-node-performance | 377 / 进阶教程 | 节点延迟低，为什么还是慢？Clash 测速与选节点指南 | `/a/clash-node-speed-test.html` | [node-performance.md](tutorials/node-performance.md)；2026-11-03本地ID377/版本1，正式ID399/版本1已发布 | 延迟、吞吐量与稳定性；`#compare` 控制条件比较、`#auto` 自动选择边界、`#timeout` 超时排查；双比例纸艺图与两组HTML图解 | | free-nodes-explained | 375 / 新手教程（client） | 免费节点是什么？能用来做什么？给第一次接触的人看 | `/a/free-nodes-explained.html` | [free-nodes-explained.md](tutorials/newcomer/free-nodes-explained.md)；本地API版本2（日常网页场景）；2026-11-03正式ID397/版本1已发布并置顶 | 零基础概念说明；`#what` 中转机制、`#uses` 用途、`#three-things` 客户端/节点/订阅、`#start` 下一步。免费节点详情页自动关联。 | | shadowrocket-id-explained | 376 / 新手教程（client） | 免费小火箭 ID 是什么？账号、客户端和节点有什么区别？ | `/a/shadowrocket-id-explained.html` | [shadowrocket-id-explained.md](tutorials/newcomer/shadowrocket-id-explained.md)；本地API版本1；2026-11-03正式ID398/版本1已发布并置顶 | 解释 App Store 账号用途；`#difference` 概念区分、`#where` 与 iCloud 区别、`#resource-page` 账号页字段、`#installed` 安装后需要节点。免费小火箭ID详情页自动关联。 | | newcomer-start | 373 / 新手教程（client） | 新手指引：从免费订阅到第一次连接 | `/a/getting-started.html` | [start.md](tutorials/newcomer/start.md)；本地API版本4（补基础说明入口）；2026-11-03正式ID393/版本2已发布 | 先选设备，再下载安装、导入对应格式的免费订阅并连接。Windows、Mac、安卓、iPhone、Linux和路由器的入口都在这里。 | @@ -123,6 +124,8 @@ ## 2 当前文章登记 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)。 +2026-11-03周期首篇测速教程正式ID399/版本1已发布，规则模式旧文升至版本2。发布、配图、点赞与验收见[测速教程发布记录](../maintenance/NODE_PERFORMANCE_2026-11-03.md)。 + 这里只登记长期编辑内容及值得复用的稳定资源说明，不逐条收录日更节点或账号文章。当前本地/正式稳定入口为 `/`（免费节点）、`/shadowrocketids`（免费小火箭ID）、`/history/freenode` 与 `/history/shadowrocketids`（对应往期）、`/client`（新手教程）、`/advanced`（进阶教程）。2026-11-03入口/往期调整已上线，实施及部署边界见[SEO实施维护](../maintenance/SEO_IMPLEMENTATION_2026-10-31.md#稳定入口与往期内容2026-11-02已本地实施未发布)；平台入口和名称修改另按项目路由核对，不从名称自行拼接。 2026-10-29部署边界更新：上表10篇已通过本站API迁移到独立test并经用户确认后切到正式cfn，旧URL保留；生产发布以预览实际正文冻结再发布，未用test整库覆盖。test和生产的临时编辑密钥均在迁移后删除，接口默认关闭；后续本地写作继续使用本地API，正式编辑按明确任务与生产绑定启用。实际部署及验收统一见[发布记录](../maintenance/RELEASE_PREFLIGHT_2026-10-28.md#正式切换2026-10-29)，上表ID仍为本地ID。 @@ -168,6 +171,11 @@ ## 3 已有文章关系 | 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本地与正式已发布 | +| clash-node-performance | newcomer-start `#devices` / newcomer-clients `#verge` | 尚未导入订阅或需要安装时回到实际操作和Resource优先下载入口 | 2026-11-03本地与正式已发布 | +| clash-node-performance | clash-routing-modes `#groups` | 比较节点前固定实际命中的代理组与出口 | 2026-11-03本地与正式已发布 | +| clash-node-performance | system-proxy-vs-tun `#troubleshoot` | 连接列表找不到目标应用时检查接管 | 2026-11-03本地与正式已发布 | +| clash-node-performance | free-nodes-explained `#free` | 解释免费节点可用性与负载变化 | 2026-11-03本地与正式已发布 | +| clash-routing-modes | clash-node-performance `#compare` | 自动选择说明之后补充延迟低但下载慢的对比方法 | 2026-11-03本地与正式已发布 | 两篇Android教程通过订阅格式段落互链；Mac下载指南与操作教程互链，Linux从下载指南和真实Linux栏目获得入口，iOS沿用真实iOS栏目入口。系统代理与TUN专题由Windows和DNS正文提供入口，并指向三平台的基础操作及DNS专题。目录、标签、导航和热门榜不算正文关联；正文内链及锚点已经本地HTTP验证。 diff --git a/docs/content/tutorials/assets/node-performance/cover.jpg b/docs/content/tutorials/assets/node-performance/cover.jpg new file mode 100644 index 00000000..250662de Binary files /dev/null and b/docs/content/tutorials/assets/node-performance/cover.jpg differ diff --git a/docs/content/tutorials/assets/node-performance/cover.png b/docs/content/tutorials/assets/node-performance/cover.png new file mode 100644 index 00000000..e4e6dad9 Binary files /dev/null and b/docs/content/tutorials/assets/node-performance/cover.png differ diff --git a/docs/content/tutorials/assets/node-performance/hero.jpg b/docs/content/tutorials/assets/node-performance/hero.jpg new file mode 100644 index 00000000..ada69e02 Binary files /dev/null and b/docs/content/tutorials/assets/node-performance/hero.jpg differ diff --git a/docs/content/tutorials/assets/node-performance/hero.png b/docs/content/tutorials/assets/node-performance/hero.png new file mode 100644 index 00000000..5fa34d6b Binary files /dev/null and b/docs/content/tutorials/assets/node-performance/hero.png differ diff --git a/docs/content/tutorials/assets/node-performance/prompts.json b/docs/content/tutorials/assets/node-performance/prompts.json new file mode 100644 index 00000000..834e1896 --- /dev/null +++ b/docs/content/tutorials/assets/node-performance/prompts.json @@ -0,0 +1,10 @@ +[ + { + "key": "cover", + "prompt": "Use case: stylized-concept. Create one polished editorial illustration for a Chinese networking tutorial, landscape EXACT 3:2 canvas 1536x1024. Theme: a low response delay does not imply high sustained download speed. Medium: tactile paper-cut collage and realistic miniature diorama, layered fibrous cardstock, small folded paper objects, soft directional shadows, rich but restrained ink colors. Entirely original composition, no device trays, no laptops, no mountains or map roads. Scene: an intimate miniature parcel sorting workshop. A little vermilion express courier carrying a single cream envelope has just reached a compact clock-shaped arch at left; at right a broad turquoise conveyor is carrying MANY orderly cream parcels into a navy sorting warehouse. Single small fast delivery vs many parcels per second is the visual metaphor. Above the scene large bold immaculate Chinese title exactly '延迟低，为什么还慢？', with comfortable breathing room. Warm ivory backdrop, muted vermilion, petrol blue and teal palette, asymmetric diagonal tabletop view, engaging adult editorial craft aesthetic, not toy plastic. Only other text is subtle clearly legible exact website watermark 'clashfreenode.com' at bottom right with safe margins; no other English, no numeric fake benchmarks. Objects, title, watermark fully within canvas. Not a generic infographic with flat icons; beautiful tangible paper sculpture." + }, + { + "key": "hero", + "prompt": "Use case: stylized-concept. Create one Chinese article hero illustration with EXACT 12:5 landscape canvas, width1920 height800, aspect2.4:1, NOT3:1 or16:9. Independently designed low wide composition about network response latency versus sustained throughput. Tactile fibrous paper collage combined with a handcrafted miniature parcel logistics diorama. In the left 40% a cream layered paper label with large dark navy Chinese typography exactly '看延迟，也看速度'; below in smaller Chinese exactly '选节点，还要看稳定性'. Along right 60% a long horizontal cross-section of a tiny parcel workshop: a red express trolley delivers one envelope through a compact brass paper stopwatch ring while a much wider turquoise paper conveyor behind it moves many cream parcels toward a paper warehouse. A row of regular small hanging warm lamps suggests consistent delivery. Camera is low oblique, different from a tall cover composition, spacious but not empty. Theme communicated by physical props, not arrows or technical chart. Palette ivory, petrol navy, muted vermilion and teal, natural soft light/shadows, real layered cut edges and folded-paper texture. No mountains, map roads, devices, trays, or potted plants. No outer borders, letterboxing or blank padded bands. Fill native12:5 frame with a deliberately arranged wide scene, never crop/stretch another picture. Exact small but crisp watermark 'clashfreenode.com' at bottom right safely inset. No other text." + } +] diff --git a/docs/content/tutorials/clash-routing-modes.html b/docs/content/tutorials/clash-routing-modes.html index 643515c1..71d29a91 100644 --- a/docs/content/tutorials/clash-routing-modes.html +++ b/docs/content/tutorials/clash-routing-modes.html @@ -1 +1 @@ -

同一个网站，规则模式打不开，切成全局却正常；明明选了新节点，连接记录里还是另一个名字。遇到这类问题，先看这条连接实际走了哪条规则、哪个代理组，再决定要改什么。

本文以 Clash Verge Rev 和 Mihomo 为例，讲清规则、全局、直连三个模式，并完成一次“只让指定网站走指定出口”的配置。还没有完成导入和首次连接，可以先看 Windows 入门教程；Mac 用户可以从对应操作步骤开始。

01　三个模式，改变的是出口选择

先确定前提：请求已经进入了客户端。系统代理、应用自身代理设置和 TUN 负责把流量送进来，下面三个模式负责决定进去以后怎样处理。未被接管的应用，不会因为切到全局就自动经过客户端；接管方式见系统代理与 TUN 的区别。

模式进入客户端后的普通业务连接适合什么时候用
规则（Rule）按当前配置匹配规则，选择直连、代理组或其他策略日常分流：不同网站使用不同出口
全局（Global）使用 GLOBAL 组当前选择的节点或策略临时对比：判断问题是否与分流结果有关
直连（Direct）由本地网络直接连接目标临时检查本地网络，或不需要代理出口时

这三个模式是路由选择，不是速度档位。全局也要检查 GLOBAL 组究竟选了什么：如果选的是 DIRECT，结果仍然是直连；如果选的是另一个代理组，还要继续看那个组的选择。Mihomo 运行模式说明

直连模式也不等于退出客户端：系统代理、TUN 等入口可能仍开启。要停用接管，需要处理对应开关，不能只把模式改成“直连”。Clash Verge Rev 名词解释

请求进入客户端后，规则模式按规则分流，全局模式使用 GLOBAL 选择，直连模式使用本地网络
图 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 里给一个网站添加规则

先选一个你确实需要调整的网站。例如，某个域名在当前网络下直连不通，而你已有能访问它的节点。只改这一项，验证后再扩展范围。

  1. 在“订阅”页面找到正在使用的配置，右键选择“编辑规则”。这里维护的是该订阅的自定义规则，可以保留在后续订阅更新中。
  2. 新增规则，类型先选 DOMAIN，内容填写连接记录里的完整主机名，例如 video.example.com。不要填 https://、路径或整个网页地址。
  3. 代理策略选择当前配置中实际存在的代理组；需要直连时选 DIRECT，需要使用节点时选相应的组，并确认组内选择。
  4. 需要覆盖订阅中已有的分流结果时，放入前置规则，同时检查前面是否还有会先命中的自定义项。不要把它追加在已兜底的 MATCH 后面。
  5. 保存并确认没有配置错误，保持规则模式，然后让目标应用重新发起连接。

界面入口与前置/后置规则的含义可参考 Verge Rev 自定义规则。这与直接改下载下来的订阅正文不同；后者可能被下一次更新覆盖。

一个网页可能同时访问登录、图片、视频和接口等多个域名。添加主站域名后页面只恢复了一部分，先查看失败连接，再补真正需要的域名。不要因为一个资源加载失败，就直接扩大成整类域名、全部应用或全部流量。

05　改完以后，检查一条新连接

验证时保持订阅、模式和接管方式稳定，只调整刚才那条规则或对应组的选择。打开“连接”页面，清除筛选，重新访问目标内容，找到刚建立的连接，逐项检查：

已有长连接不适合作为换规则、换节点后的唯一观察对象。可优先重连目标应用，或只关闭相关连接后重新测试；直接清空所有连接会影响其他正在使用的程序。

如果仍无法区分，可以做一次有控制的对比：记录当前设置，在全局模式中选择同一个明确的节点，重新建立目标连接。全局可用、规则模式不可用，提示你继续查分流和代理组；它并不能单独证明某一条规则错误，因为模式变化也可能影响其他配置行为。对比后切回规则模式，修正具体目标。

06　几种常见现象，对应查哪里

现象下一步检查
换了节点，目标连接仍走旧节点是否改错代理组、组里还有嵌套选择，以及观察的是否为旧连接
明明加了代理规则，却显示 DIRECT当前模式、规则顺序、实际域名，以及命中组是否选了 DIRECT
全局能用，规则不能用对比同一目标的新连接，确认规则模式的最终出口是否与全局相同
网页文字出现了，图片或视频失败找失败资源的域名与连接，逐项判断，不只给主站加规则
完全找不到应用的连接记录清除筛选、查看日志，再检查应用代理或 TUN 接管；规则还没到发挥作用的阶段
订阅更新后又不对了是否改了会被覆盖的订阅正文、当前配置是否切换、原代理组是否还存在

如果连接已经走了预期节点，但仍出现域名解析异常，继续检查 DNS 接管、加密和出口。如果客户端根本看不到目标流量，则回到系统代理与 TUN 的排查步骤。先根据连接记录确定问题发生在哪一步，再动对应设置，通常比不断切换三个模式更有效。

+

同一个网站，规则模式打不开，切成全局却正常；明明选了新节点，连接记录里还是另一个名字。遇到这类问题，先看这条连接实际走了哪条规则、哪个代理组，再决定要改什么。

本文以 Clash Verge Rev 和 Mihomo 为例，讲清规则、全局、直连三个模式，并完成一次“只让指定网站走指定出口”的配置。还没有完成导入和首次连接，可以先看 Windows 入门教程；Mac 用户可以从对应操作步骤开始。

01　三个模式，改变的是出口选择

先确定前提：请求已经进入了客户端。系统代理、应用自身代理设置和 TUN 负责把流量送进来，下面三个模式负责决定进去以后怎样处理。未被接管的应用，不会因为切到全局就自动经过客户端；接管方式见系统代理与 TUN 的区别。

模式进入客户端后的普通业务连接适合什么时候用
规则（Rule）按当前配置匹配规则，选择直连、代理组或其他策略日常分流：不同网站使用不同出口
全局（Global）使用 GLOBAL 组当前选择的节点或策略临时对比：判断问题是否与分流结果有关
直连（Direct）由本地网络直接连接目标临时检查本地网络，或不需要代理出口时

这三个模式是路由选择，不是速度档位。全局也要检查 GLOBAL 组究竟选了什么：如果选的是 DIRECT，结果仍然是直连；如果选的是另一个代理组，还要继续看那个组的选择。Mihomo 运行模式说明

直连模式也不等于退出客户端：系统代理、TUN 等入口可能仍开启。要停用接管，需要处理对应开关，不能只把模式改成“直连”。Clash Verge Rev 名词解释

请求进入客户端后，规则模式按规则分流，全局模式使用 GLOBAL 选择，直连模式使用本地网络
图 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 里给一个网站添加规则

先选一个你确实需要调整的网站。例如，某个域名在当前网络下直连不通，而你已有能访问它的节点。只改这一项，验证后再扩展范围。

  1. 在“订阅”页面找到正在使用的配置，右键选择“编辑规则”。这里维护的是该订阅的自定义规则，可以保留在后续订阅更新中。
  2. 新增规则，类型先选 DOMAIN，内容填写连接记录里的完整主机名，例如 video.example.com。不要填 https://、路径或整个网页地址。
  3. 代理策略选择当前配置中实际存在的代理组；需要直连时选 DIRECT，需要使用节点时选相应的组，并确认组内选择。
  4. 需要覆盖订阅中已有的分流结果时，放入前置规则，同时检查前面是否还有会先命中的自定义项。不要把它追加在已兜底的 MATCH 后面。
  5. 保存并确认没有配置错误，保持规则模式，然后让目标应用重新发起连接。

界面入口与前置/后置规则的含义可参考 Verge Rev 自定义规则。这与直接改下载下来的订阅正文不同；后者可能被下一次更新覆盖。

一个网页可能同时访问登录、图片、视频和接口等多个域名。添加主站域名后页面只恢复了一部分，先查看失败连接，再补真正需要的域名。不要因为一个资源加载失败，就直接扩大成整类域名、全部应用或全部流量。

05　改完以后，检查一条新连接

验证时保持订阅、模式和接管方式稳定，只调整刚才那条规则或对应组的选择。打开“连接”页面，清除筛选，重新访问目标内容，找到刚建立的连接，逐项检查：

已有长连接不适合作为换规则、换节点后的唯一观察对象。可优先重连目标应用，或只关闭相关连接后重新测试；直接清空所有连接会影响其他正在使用的程序。

如果仍无法区分，可以做一次有控制的对比：记录当前设置，在全局模式中选择同一个明确的节点，重新建立目标连接。全局可用、规则模式不可用，提示你继续查分流和代理组；它并不能单独证明某一条规则错误，因为模式变化也可能影响其他配置行为。对比后切回规则模式，修正具体目标。

06　几种常见现象，对应查哪里

现象下一步检查
换了节点，目标连接仍走旧节点是否改错代理组、组里还有嵌套选择，以及观察的是否为旧连接
明明加了代理规则，却显示 DIRECT当前模式、规则顺序、实际域名，以及命中组是否选了 DIRECT
全局能用，规则不能用对比同一目标的新连接，确认规则模式的最终出口是否与全局相同
网页文字出现了，图片或视频失败找失败资源的域名与连接，逐项判断，不只给主站加规则
完全找不到应用的连接记录清除筛选、查看日志，再检查应用代理或 TUN 接管；规则还没到发挥作用的阶段
订阅更新后又不对了是否改了会被覆盖的订阅正文、当前配置是否切换、原代理组是否还存在

如果连接已经走了预期节点，但仍出现域名解析异常，继续检查 DNS 接管、加密和出口。如果客户端根本看不到目标流量，则回到系统代理与 TUN 的排查步骤。先根据连接记录确定问题发生在哪一步，再动对应设置，通常比不断切换三个模式更有效。

\ No newline at end of file diff --git a/docs/content/tutorials/clash-routing-modes.md b/docs/content/tutorials/clash-routing-modes.md index a8e15e7f..c65a8c9b 100644 --- a/docs/content/tutorials/clash-routing-modes.md +++ b/docs/content/tutorials/clash-routing-modes.md @@ -36,6 +36,8 @@ 实际排查时，可以在连接详情里找策略、代理链或类似字段。不同界面展示顺序可能不同，重点是认出“命中了哪个组”和“最终使用哪个节点”。 +

自动选择更看重测试地址的响应时间，不等于下载速度排名。节点延迟很低却仍然卡顿时，可以按延迟、速度与稳定性的对比步骤做一次小范围筛选。

+

03　先看顺序，再看规则写得对不对

Mihomo 的路由规则从上往下匹配。通常前面命中的规则就决定了后续策略，因此“更精确”不会自动获得更高优先级；精确规则如果排在已经覆盖它的规则之后，仍可能用不上。涉及 UDP 等条件时，还要注意目标策略是否具备相应支持。[路由规则与优先级](https://wiki.metacubex.one/config/rules/) diff --git a/docs/content/tutorials/node-performance.html b/docs/content/tutorials/node-performance.html new file mode 100644 index 00000000..244f0101 --- /dev/null +++ b/docs/content/tutorials/node-performance.html @@ -0,0 +1 @@ +
纸艺快递车送出一封信，宽传送带持续输送包裹，分别比喻响应延迟与传输速度

节点列表里，一个显示 60 ms，另一个显示 180 ms。选了数字小的，网页却断断续续，下载也不快。这并不矛盾：延迟描述等一次响应要多久，下载速度描述一段时间能收到多少数据。 两者有关联，却不能互相换算。

挑节点，先用延迟测试排除明显不可用的选项，再用自己真正要完成的操作做比较。下面以 Clash Verge Rev 等使用 Mihomo 内核的客户端为例，说明测试数字怎么读、自动选择组怎么判断，以及遇到超时应该查哪里。

如果你还没有导入订阅，先按新手指引完成第一次连接；需要安装软件，可以从客户端下载总览选择对应版本。

01　延迟、速度、稳定性，分别看

可以把网络传输想成送包裹：第一件到得早，不代表后面每秒都能送来很多件；平均送得多，也可能时快时慢。网络里的延迟、带宽与实际吞吐量也是不同指标。延迟与吞吐量的区别

延迟：等多久一次测试要等多长时间
常见单位：ms
吞吐量：传多少持续传输时每秒收到多少数据
常见单位：Mbps、MB/s
稳定性：是否连续反复使用时会不会超时、停顿
看多次结果和实际过程
同一条线路需要从不同角度观察；延迟数字不是综合评分。

网页交互更容易让你感受到等待一次响应的时间；文件下载更依赖持续传输能力；通话等实时应用还需要关注中断、丢包和时延变化。一个短请求成功，不能代替对这些实际任务的验证。

速度单位也别看错：小写 b 表示 bit，大写 B 表示 Byte。按十进制单位换算，80 Mbps 相当于 10 MB/s；实际文件下载还受协议开销和整个传输路径影响。节点旁边的 80 ms 则是时间，和这两个速度没有这样的换算关系。

02　节点旁的数字，取决于怎么测、测哪里

在 Mihomo 的 URL 测试里，客户端通过节点向指定测试地址发起 HTTP 请求。它不是直接调用系统的 ICMP ping，也不是下载大文件测带宽。不同客户端、测试选项及内核设置可能采用不同计时方式，跨软件看到的数字不宜直接排在一起比较。

同一节点，两个不同目的地
你的设备发起请求
→
所选节点转发连接
→
测试地址得到一次延迟结果
实际使用时，最后一站换成你要访问的网站。测试地址可用，不代表这个网站的访问路径和响应情况也相同。
图中是简化路径。健康检查地址由配置决定，不能把一次测试的结果理解成“到所有网站都这么快”。

例如，健康检查很快，实际网站却响应缓慢，可能是节点到两个目的地的路径或网站服务状态不同。反过来，测试地址暂时不可用，也不能单凭一个红色结果认定该节点无法访问任何网站。健康检查的测试地址、超时时限和期望状态码都参与判断。Mihomo 代理组配置

因此，比较节点时尽量使用同一个客户端、同一个测试地址、相近时间和同一网络。先把条件固定，数字才有比较价值。

03　用一次小范围对比，找到真正好用的节点

不必把几十条免费节点全部跑满带宽。先从能通过测试的选项里挑两三条，逐条比较。

  1. 固定使用条件。 暂停正在进行的大文件下载和云盘同步，保持同一个 Wi-Fi 或有线网络。保留当前可用节点的名称，方便随时切回。
  2. 确认实际出口。 在目标网站对应的代理组中选中一个具体节点；若组里仍选择“自动选择”，测试过程中出口可能变化。打开连接记录，确认目标域名的新连接确实走了这条节点。组的嵌套关系见代理组选择说明。
  3. 看几次延迟，而不是最低一次。 隔开几秒测试三次，记下是否超时、结果是否大幅变化。三次只是快速筛选，不足以算出可靠丢包率，也不能代表全天表现。
  4. 做原本要做的事。 打开同一个实际网页，检查文字、图片和登录等操作是否完整。仅看到缓存页面秒开不能作为连接恢复的证据，要确认有新的网络请求。
  5. 确实需要下载时再看持续速度。 用同一来源、同一文件和同一下载方式，观察十几秒的持续速度与停顿，再停止测试。切到另一条节点重新建立连接后重复；别把浏览器单连接下载与测速工具的多连接峰值直接比较。

下面是一份假设记录，用于说明怎样做选择，不是节点测评结果，也不是速度及格线：

候选节点三次延迟测试同一下载任务同一网页操作
甲60 / 65 / 62 ms约 0.8 MB/s，基本连续能正常完成
乙180 / 185 / 178 ms约 4 MB/s，基本连续能正常完成
丙45 ms / 超时 / 310 ms速度跳动，数次停住偶尔失败

需要下载时，乙可能更合适；以短小网页交互为主时，可以继续对比甲与乙的实际等待感受。丙虽然出现过最低数字，但不能因此排第一。免费节点的负载和可用性会变化，这张记录只帮助你决定现在用哪条，不适合做永久排名。

04　“自动选择”为什么没有选到下载最快的？

Mihomo 的 url-test 组围绕测试地址的延迟与可用性来选节点。它不会通过持续下载每条线路的大文件，替你比较下载吞吐量，所以选中的节点可能响应很快，却不适合你的大文件任务。自动选择组说明

读配置时，先看这几个字段的含义，不必为了一个更小的数字就改配置：

字段表示什么容易误解的地方
url健康检查访问的地址不是对所有目标网站的综合检测
interval定时检查间隔，单位为秒不是连续实时测速；调短也不会增加节点带宽
timeout一次健康检查的超时限制，单位为毫秒调大只给请求更多等待时间，不会让慢连接加速
tolerance自动选择组的节点切换容差，单位为毫秒当前节点正常时，不一定为了几毫秒差异切换
lazy是否在该策略组未被选用时暂停检查看见旧测试值，不一定是客户端卡住了

如果订阅通过 use 引入 proxy-providers，还要看相应代理集合的 health-check 配置。不要以为改了代理组的测试地址，就同时改好了所有节点的健康检查。代理组通用字段与代理集合健康检查

当自动选择的结果不适合当前任务，可以在手动选择组中暂时固定到已经比较过的具体节点；使用结束后再决定是否恢复自动。直接编辑下载下来的订阅正文，可能被下一次更新覆盖；如果只是要固定选择，优先使用客户端现有的组内选择操作。

05　超时不等于只有一种故障

先观察是“一条失败”“所有测试都失败”，还是“测试正常、实际操作失败”。这三种情况的下一步不同。

现象先做什么
只有一条节点反复失败，其他正常换一条可用节点对比；这条线路暂时不可用时先跳过，不必重装客户端
所有节点测试失败，但实际网页可用检查测试地址、超时和期望状态；确认测试结果是否及时刷新
所有节点和实际访问都失败先确认本地网络正常、订阅已成功更新，再看日志中的连接错误；不要同时改 DNS、TUN 和路由
延迟正常，只有一个网站失败核对这个网站的新连接、实际出口及网站自身状态，不能用测试地址的成功替代它
切了节点，表现完全不变看实际命中的代理组，重新建立目标连接，排除旧连接、缓存或目标流量未被接管

连接列表里根本找不到目标应用时，先看系统代理与 TUN 的排查方法。如果有记录，却走了别的节点，就回到分流和组内选择。先找到问题发生的位置，再考虑改参数。

06　最后留下常用节点和一个备选

对免费节点来说，实用的选择是：当前任务能完成、连续使用没有明显停顿，再从中挑响应更合适的线路。保留一个经过同样操作验证的备选，比反复追逐列表里最低的毫秒数更方便。

普通浏览看页面与操作是否完整；下载看持续速度和停顿；通话则直接检查声音是否连贯。不同用途可以有不同选择，无需给一条节点评出适用于所有场景的总分。

如果不清楚节点为什么会失效、订阅更新又能改变什么，可以接着看免费节点的用途与限制。订阅里有多少条、测试时某一条多快，都不能保证你下一次使用时仍有同样表现。

\ No newline at end of file diff --git a/docs/content/tutorials/node-performance.md b/docs/content/tutorials/node-performance.md new file mode 100644 index 00000000..278d749c --- /dev/null +++ b/docs/content/tutorials/node-performance.md @@ -0,0 +1,101 @@ +
纸艺快递车送出一封信，宽传送带持续输送包裹，分别比喻响应延迟与传输速度
+ +节点列表里，一个显示 60 ms，另一个显示 180 ms。选了数字小的，网页却断断续续，下载也不快。这并不矛盾：**延迟描述等一次响应要多久，下载速度描述一段时间能收到多少数据。** 两者有关联，却不能互相换算。 + +挑节点，先用延迟测试排除明显不可用的选项，再用自己真正要完成的操作做比较。下面以 Clash Verge Rev 等使用 Mihomo 内核的客户端为例，说明测试数字怎么读、自动选择组怎么判断，以及遇到超时应该查哪里。 + +如果你还没有导入订阅，先按[新手指引](/a/getting-started.html#devices)完成第一次连接；需要安装软件，可以从[客户端下载总览](/a/proxy-clients.html#verge)选择对应版本。 + + + +

01　延迟、速度、稳定性，分别看

+ +可以把网络传输想成送包裹：第一件到得早，不代表后面每秒都能送来很多件；平均送得多，也可能时快时慢。网络里的延迟、带宽与实际吞吐量也是不同指标。[延迟与吞吐量的区别](https://www.cloudflare.com/learning/performance/glossary/what-is-latency/) + +
延迟：等多久一次测试要等多长时间
常见单位：ms
吞吐量：传多少持续传输时每秒收到多少数据
常见单位：Mbps、MB/s
稳定性：是否连续反复使用时会不会超时、停顿
看多次结果和实际过程
同一条线路需要从不同角度观察；延迟数字不是综合评分。
+ +**网页交互**更容易让你感受到等待一次响应的时间；**文件下载**更依赖持续传输能力；**通话等实时应用**还需要关注中断、丢包和时延变化。一个短请求成功，不能代替对这些实际任务的验证。 + +速度单位也别看错：小写 b 表示 bit，大写 B 表示 Byte。按十进制单位换算，80 Mbps 相当于 10 MB/s；实际文件下载还受协议开销和整个传输路径影响。节点旁边的 80 ms 则是时间，和这两个速度没有这样的换算关系。 + +

02　节点旁的数字，取决于怎么测、测哪里

+ +在 Mihomo 的 URL 测试里，客户端通过节点向指定测试地址发起 HTTP 请求。它不是直接调用系统的 ICMP ping，也不是下载大文件测带宽。不同客户端、测试选项及内核设置可能采用不同计时方式，跨软件看到的数字不宜直接排在一起比较。 + +
同一节点，两个不同目的地
你的设备发起请求
→
所选节点转发连接
→
测试地址得到一次延迟结果
实际使用时，最后一站换成你要访问的网站。测试地址可用，不代表这个网站的访问路径和响应情况也相同。
图中是简化路径。健康检查地址由配置决定，不能把一次测试的结果理解成“到所有网站都这么快”。
+ +例如，健康检查很快，实际网站却响应缓慢，可能是节点到两个目的地的路径或网站服务状态不同。反过来，测试地址暂时不可用，也不能单凭一个红色结果认定该节点无法访问任何网站。健康检查的测试地址、超时时限和期望状态码都参与判断。[Mihomo 代理组配置](https://wiki.metacubex.one/config/proxy-groups/) + +因此，比较节点时尽量使用**同一个客户端、同一个测试地址、相近时间和同一网络**。先把条件固定，数字才有比较价值。 + +

03　用一次小范围对比，找到真正好用的节点

+ +不必把几十条免费节点全部跑满带宽。先从能通过测试的选项里挑两三条，逐条比较。 + +1. **固定使用条件。** 暂停正在进行的大文件下载和云盘同步，保持同一个 Wi-Fi 或有线网络。保留当前可用节点的名称，方便随时切回。 +2. **确认实际出口。** 在目标网站对应的代理组中选中一个具体节点；若组里仍选择“自动选择”，测试过程中出口可能变化。打开连接记录，确认目标域名的新连接确实走了这条节点。组的嵌套关系见[代理组选择说明](/a/clash-rule-global-direct.html#groups)。 +3. **看几次延迟，而不是最低一次。** 隔开几秒测试三次，记下是否超时、结果是否大幅变化。三次只是快速筛选，不足以算出可靠丢包率，也不能代表全天表现。 +4. **做原本要做的事。** 打开同一个实际网页，检查文字、图片和登录等操作是否完整。仅看到缓存页面秒开不能作为连接恢复的证据，要确认有新的网络请求。 +5. **确实需要下载时再看持续速度。** 用同一来源、同一文件和同一下载方式，观察十几秒的持续速度与停顿，再停止测试。切到另一条节点重新建立连接后重复；别把浏览器单连接下载与测速工具的多连接峰值直接比较。 + +下面是一份**假设记录**，用于说明怎样做选择，不是节点测评结果，也不是速度及格线： + +
+ +| 候选节点 | 三次延迟测试 | 同一下载任务 | 同一网页操作 | +| --- | --- | --- | --- | +| 甲 | 60 / 65 / 62 ms | 约 0.8 MB/s，基本连续 | 能正常完成 | +| 乙 | 180 / 185 / 178 ms | 约 4 MB/s，基本连续 | 能正常完成 | +| 丙 | 45 ms / 超时 / 310 ms | 速度跳动，数次停住 | 偶尔失败 | + +
+ +需要下载时，乙可能更合适；以短小网页交互为主时，可以继续对比甲与乙的实际等待感受。丙虽然出现过最低数字，但不能因此排第一。免费节点的负载和可用性会变化，这张记录只帮助你决定**现在用哪条**，不适合做永久排名。 + +

04　“自动选择”为什么没有选到下载最快的？

+ +Mihomo 的 `url-test` 组围绕测试地址的延迟与可用性来选节点。它不会通过持续下载每条线路的大文件，替你比较下载吞吐量，所以选中的节点可能响应很快，却不适合你的大文件任务。[自动选择组说明](https://wiki.metacubex.one/config/proxy-groups/url-test/) + +读配置时，先看这几个字段的含义，不必为了一个更小的数字就改配置： + +
+ +| 字段 | 表示什么 | 容易误解的地方 | +| --- | --- | --- | +| `url` | 健康检查访问的地址 | 不是对所有目标网站的综合检测 | +| `interval` | 定时检查间隔，单位为秒 | 不是连续实时测速；调短也不会增加节点带宽 | +| `timeout` | 一次健康检查的超时限制，单位为毫秒 | 调大只给请求更多等待时间，不会让慢连接加速 | +| `tolerance` | 自动选择组的节点切换容差，单位为毫秒 | 当前节点正常时，不一定为了几毫秒差异切换 | +| `lazy` | 是否在该策略组未被选用时暂停检查 | 看见旧测试值，不一定是客户端卡住了 | + +
+ +如果订阅通过 `use` 引入 `proxy-providers`，还要看相应代理集合的 `health-check` 配置。不要以为改了代理组的测试地址，就同时改好了所有节点的健康检查。[代理组通用字段](https://wiki.metacubex.one/config/proxy-groups/)与[代理集合健康检查](https://wiki.metacubex.one/config/proxy-providers/#health-check) + +当自动选择的结果不适合当前任务，可以在手动选择组中暂时固定到已经比较过的具体节点；使用结束后再决定是否恢复自动。直接编辑下载下来的订阅正文，可能被下一次更新覆盖；如果只是要固定选择，优先使用客户端现有的组内选择操作。 + +

05　超时不等于只有一种故障

+ +先观察是“一条失败”“所有测试都失败”，还是“测试正常、实际操作失败”。这三种情况的下一步不同。 + +
+ +| 现象 | 先做什么 | +| --- | --- | +| 只有一条节点反复失败，其他正常 | 换一条可用节点对比；这条线路暂时不可用时先跳过，不必重装客户端 | +| 所有节点测试失败，但实际网页可用 | 检查测试地址、超时和期望状态；确认测试结果是否及时刷新 | +| 所有节点和实际访问都失败 | 先确认本地网络正常、订阅已成功更新，再看日志中的连接错误；不要同时改 DNS、TUN 和路由 | +| 延迟正常，只有一个网站失败 | 核对这个网站的新连接、实际出口及网站自身状态，不能用测试地址的成功替代它 | +| 切了节点，表现完全不变 | 看实际命中的代理组，重新建立目标连接，排除旧连接、缓存或目标流量未被接管 | + +
+ +连接列表里根本找不到目标应用时，先看[系统代理与 TUN 的排查方法](/a/system-proxy-vs-tun.html#troubleshoot)。如果有记录，却走了别的节点，就回到分流和组内选择。先找到问题发生的位置，再考虑改参数。 + +

06　最后留下常用节点和一个备选

+ +对免费节点来说，实用的选择是：当前任务能完成、连续使用没有明显停顿，再从中挑响应更合适的线路。保留一个经过同样操作验证的备选，比反复追逐列表里最低的毫秒数更方便。 + +普通浏览看页面与操作是否完整；下载看持续速度和停顿；通话则直接检查声音是否连贯。不同用途可以有不同选择，无需给一条节点评出适用于所有场景的总分。 + +如果不清楚节点为什么会失效、订阅更新又能改变什么，可以接着看[免费节点的用途与限制](/a/free-nodes-explained.html#free)。订阅里有多少条、测试时某一条多快，都不能保证你下一次使用时仍有同样表现。 diff --git a/docs/maintenance/NODE_PERFORMANCE_2026-11-03.json b/docs/maintenance/NODE_PERFORMANCE_2026-11-03.json new file mode 100644 index 00000000..ab7bb839 --- /dev/null +++ b/docs/maintenance/NODE_PERFORMANCE_2026-11-03.json @@ -0,0 +1,168 @@ +{ + "release_id": "3165b364-89db-497a-9cca-4c14fdcac288", + "bundle_hash": "dc1078b1bc97eb7a856dd40e2b844921d9c4e8eeb5cb53146000558f223fd72e", + "draft_id": "3165b364-89db-497a-9cca-4c14fdcac288", + "publication_request_id": "fcd5fdb7-9174-41f7-9f0a-95b21566b666", + "phase": "complete", + "review": { + "hash": "340dc14a5a3345ae0b920473452a426251041add0afce29935d6efbd7eb8c62b", + "digest": "ad37373ac0affc5c74b8bdf86f2ff0dd9d35b9f765370cee4581081c5170b461", + "rendered_at": "2026-11-03T07:41:53+00:00" + }, + "receipt": { + "publication_id": "fcd5fdb7-9174-41f7-9f0a-95b21566b666", + "status": "published", + "articles": [ + { + "content_key": "clash-node-performance", + "article_id": 399, + "revision": 1, + "content_changed": true, + "url": "https://clashfreenode.com/a/clash-node-speed-test.html" + }, + { + "content_key": "clash-routing-modes", + "article_id": 382, + "revision": 2, + "content_changed": true, + "url": "https://clashfreenode.com/a/clash-rule-global-direct.html" + } + ], + "effects": { + "indexnow": { + "status": "done", + "attempts": 1, + "http_status": 200, + "urls": [ + "https://clashfreenode.com/a/clash-node-speed-test.html", + "https://clashfreenode.com/advanced", + "https://clashfreenode.com/a/clash-rule-global-direct.html" + ], + "submitted_at": "2026-11-03T07:46:06+00:00", + "result": "received" + }, + "cache": { + "status": "done" + }, + "search": { + "status": "done", + "method": "meilisearch", + "index": "cfn_articles_v3", + "documents": 2 + }, + "sitemap": { + "status": "done", + "method": "database-driven" + } + } + }, + "published_at": "2026-11-03T07:46:05+00:00", + "readback": [ + { + "content_key": "clash-node-performance", + "article_id": 399, + "revision_matches": true, + "content_matches": true, + "body_sha256": "80685935f9601c3924442da1aca0e4c7d65441622c2b74e8f51258435ec833e8", + "like_growth": { + "seven_day_remaining": 3, + "yearly": 30, + "one_year_target": 61, + "one_year_added": 0, + "one_year_started_at": "2026-11-03 07:46:05" + } + }, + { + "content_key": "clash-routing-modes", + "article_id": 382, + "revision_matches": true, + "content_matches": true, + "body_sha256": "75a05a230e9e4f62bb5daa5262f17001430977f523e7647dec2466158bbab305", + "like_growth": { + "seven_day_remaining": 0, + "yearly": 50, + "one_year_target": 241, + "one_year_added": 2, + "one_year_started_at": "2026-10-31 06:58:28" + } + } + ], + "verification": { + "checks": [ + { + "path": "/a/clash-node-speed-test.html", + "status": 200 + }, + { + "path": "/a/clash-rule-global-direct.html", + "status": 200 + }, + { + "path": "/advanced", + "status": 200 + }, + { + "path": "/images/editorial/6e9192d1e25885928452c839407c3192cbedfa1f7ffe343f4a4b587be028fbc5.jpg", + "status": 200 + }, + { + "path": "/images/editorial/63809168da585b4e88c2cd9b24f70251b4967115b1ec4483d31d50946500027b.jpg", + "status": 200 + }, + { + "path": "/a/getting-started.html", + "status": 200 + }, + { + "path": "/a/proxy-clients.html", + "status": 200 + }, + { + "path": "/a/clash-rule-global-direct.html", + "status": 200 + }, + { + "path": "/a/system-proxy-vs-tun.html", + "status": 200 + }, + { + "path": "/a/free-nodes-explained.html", + "status": 200 + } + ], + "hero_unique": true, + "images_hash_match": true, + "links_and_anchors": true, + "quiet_template": true, + "head": "aa772e37664a27a48ddfdd378f55cc5d863034eb", + "existing_source_hashes": { + "docs/content/WRITING.md": "2ff8f8995e3e4de8e3d97779e36f04b011704bb0064039785beabffcbfd2033c", + "docs/content/tutorials/clash-routing-modes.md": "5851d347ee897447c28b2dd07cd878d86fbfd016e536b6546b2c11ea47130a5f", + "docs/content/tutorials/clash-routing-modes.html": "b1d0ed0a2854264b4163b7bf980c91722427081ee20715fb0747218c0478d4d8" + } + }, + "local": { + "new_id": 377, + "new_revision": 1, + "related_id": 366, + "related_revision": 2, + "publication_id": "006ab05b-d7b3-462b-aae1-df0c073ba6ab", + "visual_viewports": [ + "1137x1167", + "390x844", + "1340x844" + ], + "visual_scope": "详情首屏/横幅与部分正文；列表3:2容器及配图引用通过HTML和模板核对。Safari后续截图出现空白和窗口切换，未据此声称全文逐屏验收。" + }, + "sources": [ + "https://wiki.metacubex.one/config/proxy-groups/url-test/", + "https://wiki.metacubex.one/config/proxy-groups/", + "https://wiki.metacubex.one/config/proxy-providers/", + "https://www.cloudflare.com/learning/performance/glossary/what-is-latency/", + "https://raw.githubusercontent.com/MetaCubeX/mihomo/Meta/adapter/adapter.go", + "https://raw.githubusercontent.com/MetaCubeX/mihomo/Meta/adapter/outboundgroup/urltest.go" + ], + "slot": "2026-11-02-1", + "display_published_at_utc": "2026-11-03 06:33:25", + "display_offset_seconds": 4360 +} diff --git a/docs/maintenance/NODE_PERFORMANCE_2026-11-03.md b/docs/maintenance/NODE_PERFORMANCE_2026-11-03.md new file mode 100644 index 00000000..e0fc38e1 --- /dev/null +++ b/docs/maintenance/NODE_PERFORMANCE_2026-11-03.md @@ -0,0 +1,31 @@ +# 节点测速与选择教程：2026-11-03 + +状态：已在正式 cfn 的进阶教程 `/advanced` 发布。新文《节点延迟低，为什么还是慢？Clash 测速与选节点指南》，路径 `/a/clash-node-speed-test.html`，内容键 `clash-node-performance`。本地ID377/版本1；正式ID399/版本1。规则模式旧文仅在代理组说明后补一个 `#compare` 入口，本地ID366与正式ID382均升至版本2。 + +## 调度与回执 + +本次heartbeat先due，再claim槽位 `2026-11-02-1`。固定release `3165b364-89db-497a-9cca-4c14fdcac288`，发表UUID `fcd5fdb7-9174-41f7-9f0a-95b21566b666`；prepare、review、publish、status均经本机SSH→白色机→VPS-003，服务器进程内API操作，公网编辑API保持关闭。 + +真实发表时间为北京时间2026-11-03 15:46:05；展示时间14:33:25，随机提前4360秒。唯一周期台账按真实时间record，计本周第1篇。正式新文点赞冻结为i7like=3、i365like=30、一次性年度目标61，起点为真实发表时间；范围来自当前统一配置。旧文年度50、一次性241及原起点保留，未重抽。 + +缓存、Meilisearch、sitemap全部done；IndexNow由VPS-003提交新文、栏目和旧文三条URL，HTTP200/received，仅代表收到通知，不代表收录。phase=complete。脱敏机器回执见[JSON](NODE_PERFORMANCE_2026-11-03.json)；私有源稿/签名预览与发布参数在`storage/app/private/weekly-tutorials/2026-11-02-1/`，不入Git。 + +## 内容与配图 + +区分延迟、吞吐量和稳定性；解释Mihomo URL健康检查与自动选择的边界，提供少量节点的同条件对比方法和按现象排错。示例表明确为假设记录，不编造测评。2026-11-03核对Mihomo官方代理组、url-test、proxy-provider文档及当前URLTest/组选择代码，概念参照Cloudflare原文；链接保留正文和JSON。未进行客户端/节点真机联网测试，本条只留维护记录。 + +独立构思纸艺物流场景：小快递与计时器表达等待响应，宽传送带表达持续吞吐量。列表封面1536×1024（3:2），横幅1942×809（约2.4:1），分别构图、不裁切不拉伸，两图含`clashfreenode.com`水印。原PNG、JPEG和完整提示词见[素材目录](../content/tutorials/assets/node-performance/)。JPEG两图通过API保存，cover使用列表图，show_cover=false，正文仅一处`figure.guide-figure.tutorial-hero`。正文另有两组既有HTML图解，不新增公共CSS。 + +文章源、渲染HTML和实际关系以[写作索引](../content/WRITING.md)为准。新文自然关联下载、新手指引、代理组、TUN排错和免费节点基础说明；只补一处相关旧文入口。 + +## 验收范围 + +- 内置浏览器三次返回不可用，沿用用户已明确批准的Safari仅本地页面检查。1137桌面和390手机详情首屏/横幅可见，水印、比例和标题可读；1340桌面部分正文可见。后续截图出现空白及窗口切换，未声称全文逐屏检查完成。列表的既有media-3x2容器与1536×1024配图比例一致，HTML确认使用列表图，详情不重复显示cover。 +- 本地公开新文、列表和旧文均200；图片引用、唯一hero、双向入口通过。草稿API校验正文引用和锚点。 +- 正式真实模板review核对标题、六节锚点、横幅尺寸/资产、旧文签名内链和点赞冻结值；生产暂避风头模式持续开启，模板不输出机场推荐及广告。本地仍关闭，不为验收改变模式。 +- 服务器侧10项HTTPS请求均200，新文/旧文/栏目、两图SHA和五个目标锚点通过；公开正文及版本与冻结稿一致。没有在本机打开线上HTML或访问线上网站。 +- 已完成服务器侧验收，未做线上页面验收。普通正文、图片走内容API，未部署程序或公共样式。 + +## 恢复 + +继续修订用当前内容键和版本建新草稿；不重用已冻结release改内容。规则模式旧文如需退回可基于版本1创建回退草稿；新文有入向链接，撤下前先处理入口。保留公开图片和共享资产，不直接SQL或整库回滚。Git只归档本次文章源、配图、索引差异和记录，不更新生产应用HEAD。