dsh-net-switch

LIMITATIONS

Known limitations

- **只支持 HTTP CONNECT 代理**（Clash 的混合端口就是），SOCKS/PAC 会被明确拒绝并保持直连，不会静默借用别的协议。 - **子进程的 NO_PROXY 匹配弱于进程内**：进程内是自己实现的 CIDR 匹配；发布给子进程的列表里，`curl` 懂 CIDR，而 Node 自带匹配器只认主机名条目（和官方 `dsh-http-proxy` 一样）。因此子 Node 程序对私网段的绕过不如进程内精确。 - **`git clone git@…`（SSH/22）不走代理**，只覆盖 HTTP(S)。 - **`NODE_USE_ENV_PROXY=1` 会一并生效于子进程**（含模型自己写的 Node 脚本）。当前代理 URL 是 `127.0.0.1:7897` 不含账号密码；若你把 `proxy` 配成带 `user:password` 的地址，且不希望它进入子进程，请设 `publishEnvToChildren: false`。 - **`web_fetch` 是代理豁免的**：`dsh-web-fetch-http` 会把请求钉在自己校验过的地址上（它需要进程级 dispatcher 承载不了的单次请求状态），所以那一条通道不随本开关变化。LLM 调用、`web_search`、HTTP MCP 都走全局 dispatcher，会随开关变化。 - **遥测（OTLP）与部分 SDK 自带传输不受影响**：官方也说明走 `node:http` 的导出器碰不到全局 dispatcher。 - **探活是 TCP 层**的：端口开着的代理就算节点全挂也算「可达」。节点健康属于 Clash 的职责，不是 Harness 的。 - **host 代码改动在 `link:` 安装下需要重载条目**（关掉再打开，或重启）——见第 2 节。这是 DSH 的模块缓存行为，不是本插件的缺陷。 - **Clash Verge 的 TUN 模式**开着时，直连路径本身可能已被内核层接管；本插件只切 Harness 自己的出网，不去改系统网络。