网络 on Ricardo

在 macOS 上让企业 VPN 与 Clash 共存

Wed, 21 Oct 2026 00:00:00 +0800

我的 Mac 需要同时访问公司内网、国内网站和海外服务。在家要连接企业 VPN，在公司使用办公网络；个人代理原先使用 Shadowrocket。麻烦出在切换网络时：有时公司页面打不开，有时多个网站同时异常，重开两个客户端后又恢复了。

排查中还遇到了另一个问题：关闭代理测速能到两百多 Mbps，代理测速页面上却曾看到约 36 Mbps。最初很容易把这些现象归到同一个原因，但实际涉及物理链路、VPN 路由、DNS、代理节点和测速方法。

最后采用的组合是 企业 VPN 保持公司要求的模式，Clash 使用系统代理，TUN 关闭，并只给 Clash 内部增加 DNS 分流。公司规则保存在本地，节点订阅单独更新。本文记录这套配置的形成过程，以及每项测试能说明什么。

文中的公司域名、内网地址和服务器地址均使用示例值；不包含原始配置、订阅链接或账户截图。配置行为以本次使用的 Clash Verge Rev 2.5.8 和 Mihomo v1.19.32 为准。

先分清系统代理和 VPN 的职责

企业 VPN 被固定在全局模式，客户端不能切换为仅接管内网的模式。我能调整的是个人代理如何参与这条链路。

接管方式	作用范围	与企业 VPN 共存时需要留意的地方
系统代理	由遵守系统代理设置的应用把请求交给本地代理端口	部分终端程序和应用不会自动遵守，需要单独配置或显式指定代理
TUN	通过虚拟网络接口接收被路由到该接口的流量	会增加路由和 DNS 接管关系，需要与企业 VPN 一起分析

这次把 Clash 的系统代理设为 127.0.0.1:7897，保持 TUN 关闭。企业 VPN 继续负责公司的网络接入，Clash 根据规则选择直连或个人节点。系统代理、TUN 决定流量如何进入客户端，规则模式则决定进入后的流量如何出站。Clash Verge Rev 名词解释

这里有一个容易误解的地方：Clash 的 DIRECT 只表示不经过它的代理节点，连接仍然遵循 macOS 的路由。 企业 VPN 开启后，即使某个请求命中 DIRECT，也可能继续经过 VPN。反过来，Clash 连接个人节点的那条 TCP 连接也可能被 VPN 承载。下面的命令能查看路由表为目标选择的接口；实际连接还可能受接口绑定或 VPN 策略影响，不能只看策略组名字。

# 替换为自己的节点地址；这里使用文档示例地址
route -n get 192.0.2.20
scutil --proxy
scutil --dns

选择 Clash Verge Rev，主要是为了把本地规则、节点订阅和运行配置分别管理，并通过 API 验证实际命中。已有节点能继续使用，本次没有通过购买另一个客户端解决问题。Shadowrocket 保留作备用，验证 Clash 独立工作时则将它断开，避免把备用客户端提供的 DNS 或路由误认为 Clash 自身的能力。

迁移时把节点和本地规则分开

迁移后的配置包含一个节点订阅、19 个策略组和17 个规则集。节点通过 HTTP provider 每小时更新，规则集每天更新；公司域名和个人覆盖规则留在本地工作配置中。

这样刷新节点订阅时，不需要重新编辑公司内网规则，也不会因为订阅模板更新而丢掉本地调整。实际还检查了 provider 的更新时间、更新请求结果，以及重开客户端后策略组选择是否保留。

这套规则最终按下面的优先级处理流量：

优先级	匹配对象	处理方式
最前面	公司域名、localhost、列出的 IPv4 私有网段	`DIRECT`
接着	已单独验证的域名覆盖	进入指定策略组或精确直连
再往后	海外服务规则集	对应服务组或通用代理组
后面	国内域名、国内 IP、局域网规则	本地直连
最后	未匹配流量	兜底代理组

Mihomo 按规则顺序匹配；域名规则提前命中后，不会再由后面的国内 IP 规则改判。IP-CIDR 中的 no-resolve 表示不要为了这一条规则主动解析域名，并不表示后面的规则也不会解析。Mihomo 路由规则

公司域名同时配置了系统代理绕过列表和 Clash 内部的 DIRECT 规则。前者服务于遵守 macOS 代理设置的应用；后者也覆盖显式把请求交给 Clash 的程序。两层各有用途。

只给有证据的目标增加覆盖规则

Apple 的一个下载测速域名经过相邻对照，直连更快，因此只增加了精确规则：

1
2

rules:
  - DOMAIN,mensura.cdn-apple.com,DIRECT

没有因此把整个 Apple 域名体系都设为直连。

Claude 的情况则是域名覆盖不足。原规则集已包含 anthropic.com 和 claude.ai，后来补充了以下五个后缀，并统一交给 ClaudeAI：

rules:
  - DOMAIN-SUFFIX,claude.com,ClaudeAI
  - DOMAIN-SUFFIX,claude.dev,ClaudeAI
  - DOMAIN-SUFFIX,claudemcpclient.com,ClaudeAI
  - DOMAIN-SUFFIX,claudemcpcontent.com,ClaudeAI
  - DOMAIN-SUFFIX,claudeusercontent.com,ClaudeAI

其中捕获到的 bridge.claudeusercontent.com 连接，从通用代理组改为命中 ClaudeAI。这些组当时仍使用同一个节点，因此这是归类上的修正，不能直接解释为换了出口或提升了速度。

最后把“漏网之鱼”的选择从 DIRECT 改为代理。模式仍是规则模式，国内站点和公司域名继续优先匹配前面的规则。需要接受的取舍是：未被国内规则收录的站点，也可能落到兜底代理。

规则仓库和客户端如何配合

blackmatrix7/ios_rule_script 提供适配不同客户端的规则和相关脚本；本次使用的是其中的规则数据，并结合了 Loyalsoldier 的集合。haoel.github.io 则提供代理部署和网络优化的思路。它们可以作为配置来源与排查参考，不能直接替代本机的 VPN、路由和 DNS 验证。

服务端检查确认已有 VLESS Reality Vision、TCP 传输以及 BBR 和 fq。没有为这次问题继续叠加传输协议或多路复用：先确定慢在哪一段，再决定是否改服务端。

把 36 Mbps 拆成可以验证的问题

首先检查本地链路。有线网络那次故障中，当前网络位置缺少实际 USB 网卡对应的服务，旧服务绑定的接口已不存在。补齐服务并获取 DHCP 地址后，有线恢复，协商结果为 100baseTX full-duplex。

这个结果说明当时那条以太网链路的协商速率是 100 Mbps，不是运营商套餐的上限。Wi-Fi 显示的连接速率也属于无线链路指标，不能直接当作应用下载速度。服务器面板里的每月流量额度则是累计传输量，与 Mbps 带宽又是两个单位。

后续连接环境发生过变化，另一次有线记录已是千兆全双工，因此不能把下面超过 100 Mbps 的结果套到前述百兆链路上。换不同目标做限量测试后，也发现“代理固定只能跑 36 Mbps”的解释并不成立：

测试	当时结果	可以说明的范围
Cloudflare 页面完整测试	下载约 142 Mbps，上传约 44.6 Mbps	该次完整页面测试的结果
同一页面的 1 MB 阶段	中位数约 35.7 Mbps	小文件阶段可能明显低于完整结果
Mac 经代理下载 Cloudflare 测试文件	约 134 Mbps	当时代理路径可以超过 36 Mbps
Apple 限量双连接下载	直连约 186 Mbps，代理约 165 Mbps	同一目标下代理有开销，但并非固定 36 Mbps
VPS 本机短时入站下载	约 1.47 Gbps	服务器在该短样本中能够超过千兆

这些不是同一轮测试的所有分支，不能拼成一张精确的带宽损耗图。最后一项也没有证明 VPS 套餐的端口上限，更不能保证从家里到服务器的跨境链路达到同样速度。

测速还要检查 HTTP 状态码。一次多连接样本拿到的是 403，应作为无效吞吐样本排除；测速网页里的 WebRTC 或 UDP 指标，也不能直接当作 VLESS TCP 隧道的丢包率。

DNS 结果不同是否就会让代理变慢

针对 Claude 和 Anthropic，做过一轮相邻的企业 VPN 开启、关闭、重新开启测试。过程中没有清理 DNS 缓存，也没有修改代理配置。

结果很明确：VPN 开启时，系统解析出现一组特定 CNAME 和地址；关闭后恢复为公共解析结果；重新开启后又回到前一组。同期直接查询家庭路由器和通过代理查询公共 DoH，返回的仍是公共结果。

这说明差异与 VPN 启用后的 DNS 路径 有关。它还不足以说明是客户端 Bug、恶意污染，或之前整机断网的根因。

接下来保持 Host、SNI 和证书校验不变，对不同地址实际建立连接。在当时的正常 Clash 代理路径上，Anthropic 普通域名请求与固定公共 IP 请求的首字节耗时中位数分别约为 804 ms 和 807 ms；Claude 为 801 ms 和 794 ms，差别很小。

还有一个更容易误判的现象：连接面板里显示过某个解析地址，正常域名请求却能成功；强制代理节点连接这个地址时反而发生 TLS 错误。对于保留域名的 VLESS TCP 请求，目标可能交给远端继续解析；实际行为还受 metadata 状态影响。因此，单看客户端的 destinationIP，不能证明服务器最终拨号的就是这个地址。Mihomo v1.19.32 VLESS 实现、metadata 处理

另一轮在 VPN 关闭时，把 Mac 经过代理的请求与 VPS 本机请求放在同一时段比较：

目标	Mac 经代理的首字节耗时	VPS 本机的首字节耗时
Anthropic trace	约 818 ms	约 43 ms
Claude trace	约 801 ms	约 28 ms

Mac 到节点端口的 TCP 建连中位数约 195 ms；同一连接复用后，请求耗时从约 787 ms 降到约 198 ms、192 ms。这个组合更支持继续检查客户端到节点的链路和连接建立成本，而不是直接给目标网站固定 IP。这里测的是小型 HTTP trace 请求，不是模型首 token 时间。

只给 Clash 增加内部 DNS 分流

最后增加 DNS 分流，目的是明确不同域名的解析路径。它没有把整台 Mac 的 DNS 都改成交给 Clash，也不以提高所有网站速度为前提。

采用的分工是：

公司域名、局域网域名和未匹配域名继续用 system。
国内域名集合使用国内 DNS。
Claude 相关域名通过 ClaudeAI 查询境外 DoH，其他已知境外域名经 DNS_Proxy 查询。
节点域名单独配置直接可用的解析器，避免“先有代理才能查 DNS、先查 DNS 才能连接代理”的循环。

下面是脱敏后的 配置片段。它要求已有 ClaudeAI、DNS_Proxy 策略组，以及 cn-domains、proxy-domains 规则集；应将名称对应到自己的配置，不能单独当作完整订阅启动。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  ipv6: true
  prefer-h3: false
  use-hosts: true
  use-system-hosts: true
  respect-rules: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - "223.5.5.5#DIRECT"
    - "119.29.29.29#DIRECT"
  nameserver:
    - system
  nameserver-policy:
    "+.corp.example": [system]
    "+.local": [system]
    "+.lan": [system]
    "+.arpa": [system]
    "localhost": [system]
    "+.anthropic.com":
      - "https://1.1.1.1/dns-query#ClaudeAI"
      - "https://8.8.8.8/dns-query#ClaudeAI"
    "+.claude.ai":
      - "https://1.1.1.1/dns-query#ClaudeAI"
      - "https://8.8.8.8/dns-query#ClaudeAI"
    "+.claude.com":
      - "https://1.1.1.1/dns-query#ClaudeAI"
      - "https://8.8.8.8/dns-query#ClaudeAI"
    "+.claude.dev":
      - "https://1.1.1.1/dns-query#ClaudeAI"
      - "https://8.8.8.8/dns-query#ClaudeAI"
    "+.claudemcpclient.com":
      - "https://1.1.1.1/dns-query#ClaudeAI"
      - "https://8.8.8.8/dns-query#ClaudeAI"
    "+.claudemcpcontent.com":
      - "https://1.1.1.1/dns-query#ClaudeAI"
      - "https://8.8.8.8/dns-query#ClaudeAI"
    "+.claudeusercontent.com":
      - "https://1.1.1.1/dns-query#ClaudeAI"
      - "https://8.8.8.8/dns-query#ClaudeAI"
    "rule-set:proxy-domains":
      - "https://1.1.1.1/dns-query#DNS_Proxy"
      - "https://8.8.8.8/dns-query#DNS_Proxy"
    "rule-set:cn-domains":
      - "223.5.5.5#DIRECT"
      - "119.29.29.29#DIRECT"

nameserver-policy 指定域名的解析上游，#ClaudeAI 指定上游连接使用的代理组。没有另设 direct-nameserver，让直接连接的解析也继续遵循域名策略，避免用公共 DNS 覆盖公司域名的解析路径。Mihomo DNS 配置

这里保留未知域名走 system，是为了兼容未完整列出的内网名称。所以，流量兜底走代理，与未知域名的 DNS 也走海外 DoH，是两项不同设置。 本次只实现了前者。

system 也有版本边界：v1.19.32 在 macOS 上读取 /etc/resolv.conf 的 nameserver 列表，约五分钟的刷新阈值由查询触发，并非完整复刻 macOS 的 scoped DNS 选择机制。切换 VPN 后的行为需要另外验证。system DNS 实现、POSIX 解析器读取

先隔离验证再应用

修改前备份工作配置、生成的运行配置、策略选择和应用设置，再运行核心配置校验。

真正应用前，先启动临时实例：使用另一个代理端口、独立控制接口和规则缓存，不改变系统代理。临时实例必须等规则集全部加载完成再测试；API 已经开始监听，不代表所有规则和数据文件都已就绪。

验证包括公司域名的系统访问与显式代理访问、Claude 和 Anthropic 的 HTTPS 请求、国内网站，以及 1053 的 TCP 和 UDP 查询。还要看实际命中的规则，不能只凭 YAML 内容判断已经生效。

# 查看系统仍在使用哪些 DNS
scutil --dns

# 单独验证 Clash 内部解析，替换示例公司域名
dig @127.0.0.1 -p 1053 devops.corp.example A
dig @127.0.0.1 -p 1053 claude.ai A +tcp

# curl 显式走 Clash，避免依赖它是否读取系统代理
curl --proxy http://127.0.0.1:7897 --noproxy '' \
  --connect-timeout 8 --max-time 15 \
  -o /dev/null -w 'code=%{http_code} total=%{time_total}\n' \
  https://claude.ai/cdn-cgi/trace

# 验证系统解析和路由；仍可能经过企业 VPN
curl --noproxy '*' --connect-timeout 5 --max-time 10 \
  -o /dev/null -w 'code=%{http_code}\n' \
  http://devops.corp.example/

正式应用后，公司入口返回正常 302 跳转，Claude、Anthropic、百度、B 站请求返回 200，Google 探针返回 204。公司规则、订阅每小时更新、40 条路由规则和策略组选择都保留；系统 DNS 没有改动，TUN 仍关闭。这些结果验证的是解析与请求连通性，不代表所有登录流程、Claude Code 任务或长连接都已覆盖。

首次并发验证中，境外 DoH 曾耗时约 4.4 秒，Claude 请求约 7.67 秒。随后在同一网络同时运行旧、新配置，两轮 Claude 总耗时分别是 1.920 / 1.926 秒 和 1.277 / 1.280 秒，未见明显回归。冷启动开销和链路波动仍然存在。

此前在内部 DNS 关闭时，做过保持 Clash 进程不变、反复关闭和连接企业 VPN 的测试，公司内网和外网请求能够恢复；但新 DNS 配置后的对应测试被中断，尚未完成。因此目前能确认的是这份配置已生效、当前路径可用，不能据此承诺以后切网都无需等待或重启。

下次遇到异常，我会先保留当时的进程、路由、DNS 和请求结果，再逐项切换。只有保留下失败现场，才有机会分清究竟是解析器没有切换、节点链路波动，还是应用持有的旧连接还没恢复。

斐讯 K2 从 Padavan 刷 OpenWrt 24.10.8

Sat, 03 Oct 2026 17:30:00 +0800

最近在学习 VLAN、子网、路由和家庭组网，手里正好有一台闲置多年的斐讯 K2。它之前已经刷成 Padavan，但管理页面切换一次经常需要 30 秒左右，于是决定把它重新刷成 OpenWrt，当作网络实验机。

这篇文章记录这次实际操作过程。设备和 Breed 版本不同，操作方式可能不同，刷机前一定先确认自己的型号和 Flash 布局。

一、设备信息

路由器铭牌信息：

型号：斐讯 K2 / PSG1218
硬件版本：A6
SoC：MediaTek MT7620A
RAM：64 MB DDR2
Flash：Winbond W25Q64，8 MB
当前系统：Padavan 3.4.3.9-099
Bootloader：Breed 1.1 r1033

Padavan SSH 中可以看到：

1
2
3

MediaTek SoC: MT7620A, RevID: 0206, RAM: DDR2, XTAL: 20MHz
CPU/OCP/SYS frequency: 580/193/193 MHz
SPI flash chip: W25Q64BV (ef 40170000) (8192 Kbytes)

当前 Flash 分区：

0x000000000000-0x000000030000 : "Bootloader"
0x000000030000-0x000000040000 : "Config"
0x000000040000-0x000000050000 : "Factory"
0x000000050000-0x00000016c2d0 : "Kernel"
0x00000016c2d0-0x0000007c0000 : "RootFS"
0x0000007c0000-0x000000800000 : "Storage"
0x000000050000-0x000000800000 : "Firmware_Stub"

固件从 0x50000 开始，这一点后面选择 K2 v22.4 profile 时很重要。

二、先判断 Padavan 卡顿是不是硬件问题

Padavan 后台非常卡，但路由器本身负载并不高，所以先测试局域网延迟：

`1`	`ping 192.168.123.1`

实际结果平均只有约 1 ms，并且没有丢包。同时 Padavan 页面显示 CPU 占用很低、还有约 30 MB 空闲内存。

因此更像是旧 Padavan/Web 服务或配置问题，而不是单纯网络链路太慢。

既然本来就准备把 K2 当实验机，最终没有继续修旧 Padavan。

三、确认 Breed

Breed 可以理解为路由器上的 Bootloader/救援环境，有点类似 PC 的 BIOS/UEFI。只要 Breed 本身还在，即使后面的 OpenWrt 刷坏了，一般仍有机会重新刷固件恢复。

进入 Breed 的方法：

K2 断电。
按住 RESET。
保持 RESET 的同时通电。
等几秒后松开 RESET。
电脑有线连接 LAN 口。
将电脑放到 192.168.1.0/24 网段。
浏览器访问 http://192.168.1.1。

这台机器成功进入 Breed，显示：

Breed 版本：1.1 (r1033)
CPU：MediaTek MT7620A
内存：64MB DDR2
Flash：Winbond W25Q64 8MB

四、刷之前一定先备份

在 Breed 的「固件备份」页面分别保存：

1
2
3

eeprom.bin
firmware.bin
full.bin

其中：

eeprom.bin：Factory/EEPROM 数据，包含无线校准等设备相关信息，非常重要。
firmware.bin：当前 Padavan 固件备份。
full.bin：完整 Flash 备份，适合严重故障时恢复。

这三个文件建议至少保存两份。

刷机过程中不要随便执行：

1
2
3

mtd erase ...
mtd write ...
dd ... of=/dev/mtd...

尤其不要乱写 Bootloader 和 Factory 分区。

五、选择 OpenWrt 固件

最终选择：

1
2
3

OpenWrt 24.10.8
Target: ramips/mt7620
Device: Phicomm K2 v22.4 or older

官方目录：

https://downloads.openwrt.org/releases/24.10.8/targets/ramips/mt7620/

下载了两个文件：

1
2

openwrt-24.10.8-ramips-mt7620-phicomm_k2-v22.4-initramfs-kernel.bin
openwrt-24.10.8-ramips-mt7620-phicomm_k2-v22.4-squashfs-sysupgrade.bin

这台 K2 的 Padavan Flash 布局中 firmware 从 0x50000 开始，与 v22.4 profile 对应。正式启动 OpenWrt 后，LuCI 最终也识别为：

`1`	`Phicomm K2 v22.4 or older`

校验 SHA256

不要跳过固件校验。

initramfs：

`1`	`shasum -a 256 ~/Downloads/openwrt-24.10.8-ramips-mt7620-phicomm_k2-v22.4-initramfs-kernel.bin`

得到：

`1`	`63fd43bd57e499e10e05fbaa46551a5150fa087f16c7030d348c9f77ff2539f2`

sysupgrade：

`1`	`shasum -a 256 ~/Downloads/openwrt-24.10.8-ramips-mt7620-phicomm_k2-v22.4-squashfs-sysupgrade.bin`

得到：

`1`	`da17725d7b626b67feeed0a4b3ccb71970238539450f43d5b36426cccb344dc8`

都与 OpenWrt 官方 SHA256 一致后再继续。

六、先进入 OpenWrt recovery/initramfs

这次没有一上来就在 OpenWrt 中永久写入 sysupgrade，而是先进入 OpenWrt 的 recovery/initramfs 环境。

成功后 LuCI 顶部会看到类似提示：

`1`	`System running in recovery (initramfs) mode.`

此时 OpenWrt 是临时运行状态。

确认页面能够正常打开、设备型号能够识别后，再进行正式安装。

不同 Breed 版本提供的启动/刷写方式可能不同。这里最重要的是先确认自己已经进入 OpenWrt recovery/initramfs，再执行下面的 sysupgrade，而不是照搬其他型号路由器的 Breed 参数。

七、正式刷入 OpenWrt

进入 recovery OpenWrt 后：

1
2
3

System
→ Backup / Flash Firmware
→ Flash new firmware image

选择：

`1`	`openwrt-24.10.8-ramips-mt7620-phicomm_k2-v22.4-squashfs-sysupgrade.bin`

下面是这次刷机时的实际截图：当前仍处于 recovery/initramfs 模式，选择的是 K2 v22.4 的 sysupgrade 固件，文件大小为 6.25 MiB。

点击 Upload 后还会进入校验确认页面，此时尚未开始正式写入 Flash。

上传以后 OpenWrt 会再次显示文件大小和 SHA256。

实际看到：

1
2

Size: 6.25 MiB
SHA256: da17725d7b626b67feeed0a4b3ccb71970238539450f43d5b36426cccb344dc8

这里再次确认 SHA256 与 Mac 本地以及官方值一致。

由于是从 Padavan 全新切换到 OpenWrt，我取消了：

`1`	`Keep settings and retain the current configuration`

然后点击 Continue 开始写 Flash。

写入期间：

不断电。
不按 RESET。
不拔网线。
不刷新页面。

等待路由器完成写入和重启。

八、第一次启动

正式 OpenWrt 启动后访问：

`1`	`http://192.168.1.1`

LuCI 显示：

Model: Phicomm K2 v22.4 or older
Firmware Version: OpenWrt 24.10.8
Kernel Version: 6.6.144
Target Platform: ramips/mt7620

这说明 profile 选择正确，刷机成功。

第一件事先设置 root 密码，然后通过 SSH 检查：

ssh root@192.168.1.1

df -h
free -m
uptime
cat /proc/mtd

最终 Flash 分区类似：

mtd0: "u-boot"
mtd1: "u-boot-env"
mtd2: "factory"
mtd3: "firmware"
mtd4: "kernel"
mtd5: "rootfs"
mtd6: "rootfs_data"

Breed 和 Factory 都还保留着。

九、8MB Flash 的现实限制

刷完以后：

1
2

/overlay 总空间约 1.4 MB
剩余约 1.2 MB

所以 K2 跑 OpenWrt 最大的问题不是 CPU，而是 Flash 和 RAM 太小。

看到：

`1`	`/dev/root 100%`

不用紧张。OpenWrt 的 /dev/root 是只读 SquashFS，显示 100% 属于正常现象。真正需要关注的是可写的 /overlay。

这台 K2 比较适合：

学 VLAN。
学 DHCP。
学静态路由。
学 NAT 和防火墙。
学 DNS。
测试 Wi-Fi 网络隔离。

不适合：

OpenClash。
Passwall。
AdGuard Home。
大量 LuCI 插件。

只有 1 MB 左右的可写空间，随便安装几个软件包就可能把 Flash 填满。

十、无线还能不能用？

可以。

刷 OpenWrt 后并不是无线功能消失了。K2 的官方 OpenWrt profile 已包含对应无线驱动，通常不需要另外安装驱动模块。

OpenWrt 首次启动时无线可能默认关闭，在：

`1`	`Network → Wireless`

配置 SSID、加密方式并启用即可。

如果无线页面没有识别到 Radio，可以通过 SSH 检查：

wifi status
iwinfo
ls /sys/class/ieee80211/
dmesg | grep -Ei 'mt76|wifi|wlan|80211'
opkg list-installed | grep -E 'mt76|mac80211|wireless|wpad'

K2 的 Flash 太小，不要看到无线没开启就先执行 opkg install，应该先确认驱动是否已经存在。

总结

这次实际升级路径可以概括成：

K2 PSG1218 A6
      ↓
Padavan
      ↓
确认 Breed
      ↓
备份 EEPROM / Padavan / Full Flash
      ↓
OpenWrt 24.10.8 v22.4 initramfs/recovery
      ↓
校验 sysupgrade SHA256
      ↓
OpenWrt sysupgrade
      ↓
OpenWrt 24.10.8

对一台 8MB Flash、64MB RAM 的老 K2 来说，OpenWrt 24.10.8 已经比较吃紧，不适合继续堆插件。但拿来做 VLAN、子网、路由、DHCP、防火墙等网络实验，反而是个不错的废物利用方式。

参考

OpenWrt Phicomm K2：https://openwrt.org/toh/phicomm/k2
OpenWrt 24.10.8 ramips/mt7620：https://downloads.openwrt.org/releases/24.10.8/targets/ramips/mt7620/