diff --git a/NETWORK.md b/NETWORK.md
index 0f283fe..63d86b7 100644
--- a/NETWORK.md
+++ b/NETWORK.md
@@ -151,7 +151,69 @@
 
 ---
 
-## 五、后续维护原则
+## 五、执行准则（Val 网络排查与配置决策规则）
+
+这部分不是背景说明，而是后续遇到网络问题时应优先执行的规则。
+
+### 规则 1：默认假设“直连优先”，不要先入为主全局挂代理
+除非已有明确证据，否则先不要把问题归因为“必须全局代理”。
+
+优先排查：
+- 是本地问题？
+- 是目标服务本身问题？
+- 是单一能力链路问题？
+- 是海外访问问题？
+
+### 规则 2：按“能力”排查，不按“OpenClaw 整体”排查
+正确拆法应是：
+- 主聊天模型链路
+- Telegram 链路
+- Gmail / Google 链路
+- web_search / web_fetch / browser 链路
+- 其它外部集成链路
+
+不要把“某个能力失败”直接等同为“OpenClaw 都需要代理”。
+
+### 规则 3：新增服务前，先做直连/代理双测
+至少做两种测试：
+1. 直连是否成功
+2. 经 `127.0.0.1:7897` 是否成功
+
+然后再归类为：
+- 必须代理
+- 建议直连
+- 视场景而定
+
+### 规则 4：新增 provider / channel / integration 后，立即更新本文件
+每次新增能力后，补充：
+- 服务名称
+- 类型（模型 / channel / API / web / 集成）
+- 地域属性（国内 / 海外 / 中转）
+- 直连结果
+- 代理结果
+- 最终推荐策略
+
+### 规则 5：优先做能力级分流，不做粗暴全局翻墙
+目标是：
+- 降低复杂度
+- 降低误判
+- 提高稳定性
+- 让网络问题更容易定位
+
+### 规则 6：遇到“体感上全部坏了”，先检查三件事
+1. 当前会话实际使用的模型/provider 是什么
+2. 当前失败的是模型链路，还是工具链路 / channel 链路
+3. 代理切换过程中是否出现端口无人监听、服务重启、短时超时
+
+### 规则 7：Telegram / Google 作为已知高优先级代理对象优先处理
+当相关能力异常时，优先检查：
+- mihomo 是否运行
+- `127.0.0.1:7897` 是否可用
+- 相关配置是否显式指向代理
+
+---
+
+## 六、后续维护原则
 
 ### 原则 1：不要把“OpenClaw 要不要走代理”当成全局问题
 正确问题应当是：
@@ -174,7 +236,7 @@
 
 ---
 
-## 六、建议的后续扩展字段（以后可加）
+## 七、建议的后续扩展字段（以后可加）
 
 后面如果服务和模型越来越多，可以在本文件中追加表格字段：