从买 DMIT 到 Clash 分流：我的网络实战教程

我已经买了 DMIT 的 VPS，也在 Mac 上用 Clash Verge 连通了它。

但老实说，能用不等于真的看懂。

DMIT 商品页上的配置、Mac Wi‑Fi 里的各种选项、Clash 里的 TUN 和规则，随便点开一个都能冒出一堆陌生词。

所以这篇不准备从网络词典开始背。

我们只沿着一条真实路线往下走：先看懂这台 Mac 的数据从哪里出去，再弄清 DMIT 在中间做什么，最后让不同网站稳定走向我们指定的出口。

概念遇到了再解释，前面已经讲过的，后面就不重新抄一遍。

整套教程只沿着一条主线前进：

先看清当前网络
→ 学会购买 VPS
→ 看懂 VPS 怎样变成代理出口
→ 看懂 Mac 本地网络
→ 看懂 Clash 怎样接管流量
→ 理解切换节点的实际影响
→ 建立自己的分流规则
→ 选择合适的客户端
→ 比较机场与自建 VPS
→ 用整套知识排查 Claude 和其他网站的问题

文中的截图来自当前这台 Mac、Clash Verge 和 DMIT 账户，账号、Wi‑Fi 名称等信息已经脱敏。

这篇文章的核验日期是 2026 年 7 月 19 日。

软件版本、产品价格和平台政策都会变化，以后照着操作时，记得再看一眼官方页面。

第一章：先画出我现在真正的上网路线

先不讨论该买什么，也不急着背协议。

我们先回答一个最实际的问题：现在打开 Claude、YouTube 或一个国内网站时，数据究竟从哪里出去？

这条路线如果没看清，Wi‑Fi、Clash、节点、VPS 和 VPN 很容易在脑子里搅成一团。

当前这台 Mac 的真实路线，其实可以先压缩成一句话：

应用发出请求，Mac 把请求交给 Clash，Clash 再决定直接访问网站，还是先送到 DMIT 后再访问网站。

现阶段先认清这几个位置就行。

端口、TUN 和节点协议先别急，后面真正看到对应设置时再讲。

flowchart LR
    A["浏览器、App 或命令行程序"] --> B["macOS 网络系统"]
    B --> C["Clash Verge / Mihomo"]
    C --> D{"规则判断"}
    D -->|"DIRECT 直连"| E["家庭路由器与运营商"]
    D -->|"PROXY 代理"| F["DMIT VPS"]
    E --> G["目标网站"]
    F --> G

拿打开 claude.ai 举例。

Chrome 是发出请求的软件，Claude 的后台是接收请求、返回内容的服务器。

正式连接前，claude.ai 要先变成可连接的网络地址。

这个查地址动作由浏览器、系统或 Mihomo 完成，取决于当前 DNS 和代理配置。

确认目标后，Mac 再把请求交给家庭网络或 Clash。

这里第一次需要认识 IP。

说白了，它就是网络里的地址。

Mac 在家里有一个内网 IP，可以把它理解成“家里的座位号”。

但是 Claude 看不到这个座位号，它看到的是请求离开本地网络时使用的出口 IP。

请求直连时，出口来自当前宽带；请求经过 DMIT 时，出口就变成 DMIT 服务器使用的 IP。

所以 IP 不是人的永久身份证，也不是精确的 GPS。

它更像“这一次网络连接从哪个门出去”，能反映大致地区和所属网络。

现在做第一次验证。

先在关闭 Clash 和开启 Clash 的两种状态下，分别打开一个 IP 查询页，记下页面显示的 IPv4、IPv6 和地区。

然后进入 Clash Verge 的“连接”页面，搜索刚才访问的域名，看它走的是 DIRECT 还是 PROXY。

IPv4 和 IPv6 是两套地址。

一台设备可以同时使用它们，所以要分开记录。

否则很容易出现 IPv4 已经走 DMIT，IPv6 却还在直连，而我们只看一眼就以为“全都代理成功了”。

成功标志：你能说出这次请求走的是家庭网络还是 DMIT，以及网站最后看到了哪个出口。

我们已经找到 DMIT 在路线中的位置，现在只剩一个现实问题：商品页上的地区、线路、CPU、内存和流量，哪些真正值得花钱？

第二章：买 DMIT 前，先看懂自己到底在买什么

第一章已经确定了 VPS 在整条路线里的位置。

它就是一台放在远处的虚拟电脑。

装好网络服务以后，它才能成为我们的出口。

选购时真正要解决的，不是“哪台配置最高”，而是“哪台最适合我的用途”。

如果只是做个人代理出口，地区、线路和流量，往往比一味堆 CPU 更重要。

打开 DMIT 官方定价页，最先看到三个筛选项：Location、Network Series 和 Hardware Platform。

大白话翻译一下，就是：服务器放在哪里、走哪类网络线路、运行在什么硬件平台上。

选完这三项，下面才会出现 CPU、内存、硬盘、月流量、端口速率和价格。

下面这张图重点看页面中间的三个筛选区域：

截图里选中的是 LAX、Premium 和 AS3。

它只用来演示三个筛选项，不是我现在这台 AN5 实例的套餐页，别把两者混在一起。

Location 决定服务器放在哪里。

LAX 是洛杉矶，HKG 是香港，TYO 是东京。

位置会影响两段路：你的电脑到 VPS，以及 VPS 到目标网站。

但是离得近，不代表一定更稳。

网络并不是照着地图走直线，还要看运营商把数据绕到了哪里。

这里会遇到两个常见词：延迟是数据来回一次要花多久，丢包是有些数据在路上没能成功到达。

选地区时，先看目标网站允许什么地区，再比较白天和晚高峰的延迟、丢包和速度。

Network Series 决定数据用什么线路到达服务器。

DMIT 当前分成 Premium、Eyeball 和 Tier 1。

先不用背复杂线路名，只记住这个粗略区别：Premium 更重视中国大陆和亚太方向的连接；Eyeball 在价格与体验之间折中；Tier 1 更偏普通国际网络和成本。

商品页写“低延迟”只能当参考。

真正有用的，是你用自己的宽带在白天和晚高峰各测一次。

Hardware Platform 是承载 VPS 的硬件平台。

AN5、AN4、AS3 代表不同代际。

只运行轻量代理服务时，不用先被硬件型号吓住，优先看线路、流量和价格。

以后还要在同一台机器上跑网站、数据库或转码，再认真比较 CPU 和内存。

选完以后，套餐列表会长这样。

这里先看 TINY 一行里分别给了多少 CPU、内存、硬盘、流量和端口速率：

vCPU 是分给这台虚拟电脑的计算能力，RAM 是程序运行时使用的内存，SSD 是放系统、配置和日志的硬盘。

如果只跑一个轻量代理服务，1 vCPU、2 GB 内存和 20 GB SSD 已经能覆盖个人使用的基本需求。

但这不是万能答案。

以后服务变多、连接人数增加，或者还要跑别的应用，配置需求也会跟着涨。

月流量和端口速率最容易被看成一回事。

月流量是“这个月一共能用多少水”，端口速率是“这根水管瞬间能有多粗”。

所以页面写着 1 Gbps，不代表你任何时候都能跑满，更不代表流量无限。

真实速度还会被本地宽带、国际线路、服务器负载和目标网站一起限制。

再回到我现在真正使用的这台 DMIT。

它的套餐名是 LAX.AN5.Pro.TINY，控制台显示 1 vCPU、2 GB RAM、20 GB SSD，以及每月 1000 GB 双向流量。

“双向”表示上传和下载都会计入额度，不是只计算下载。

下面两张图只保留了套餐和流量信息，账户、主机名与公网地址已经去掉。

看到套餐名、CPU、内存、硬盘和 1000 GB 总额度都能对上，就说明我们没有拿商品页上的其他套餐来解释自己的机器。

公网 IPv4 也是你买到的资源。

VPS 的 IP 来自数据中心，所以它属于机房 IP。

这里的“静态”是指：在服务商没有重新分配地址的前提下，这台实例持续使用同一个 IP。

“独享”表示当前由这一实例使用。

静态和独享都不等于住宅 IP，也不等于“绝对干净”。

这里还会看到 ASN。

你可以先把它理解成“这个 IP 属于哪家网络的编号”。

它能帮我们判断出口来自 DMIT、家庭宽带还是其他运营者。

但任何一个查询网站都不是最终裁判。

IP 定位库、黑名单库和目标网站使用的数据不同，一个页面显示正常，不代表所有平台都会给出相同评价。

真要下单时，按这个顺序看就行：

先写清用途和目标地区。
再选机房与 Network Series。
使用 Looking Glass，也就是商家开放的线路测试页，分别检查白天和晚高峰的延迟与丢包。
确认流量是单向还是双向，超量后收费还是限速，以及是否包含公网 IPv4、IPv6。
最后再比较 CPU、内存、硬盘、价格和退款条件。

DMIT 的产品和价格会调整，真正付款时以结算页为准。

买完以后，我们手里仍然只是一台能运行 Linux 的远程电脑。

网站不会因为你付了钱，就自动看到这台机器的 IP；Mac 也不会凭空知道该怎样连接它。

下一章先把“空 VPS 变成代理出口”的结构拆开。

真实安装命令目前还缺正确的 SSH 登录凭证，所以只讲已经核验的部分，不瞎补。

第三章：从空 VPS 到代理出口，中间发生了什么

从“买到服务器”到“Clash 里出现一个节点”，中间至少发生了五件事：

VPS 安装操作系统。
服务器里安装并启动代理程序。
代理程序打开一个端口，等待客户端连接。
Mac 拿到服务器地址和认证信息。
两边按同一套规则建立连接。

少任何一项，VPS 都不会自动变成代理。

flowchart LR
    A["购买 VPS"] --> B["安装 Linux"]
    B --> C["安装并启动服务端程序"]
    C --> D["监听端口并设置认证"]
    D --> E["生成节点配置"]
    E --> F["Clash 导入并连接"]
    F --> G["VPS 成为出口"]

VPS 先要有一个操作系统，个人服务器常见的是 Debian 或 Ubuntu。

它就像一台新电脑里的基础系统，后面的代理程序都要运行在它上面。

管理这台远程电脑，常用的是 SSH。

你可以把它理解成“从自己 Mac 的终端，远程进入 VPS 干活”。

代理程序启动后，还要在一个端口上等待连接。

所谓“监听端口”，说白了就是在服务器上开一扇指定的门，等 Mac 来敲。

如果防火墙把这扇门挡住了，就算里面的程序运行正常，外面的 Mac 也连不进去。

我已经在当前 Clash 配置中核对过这条节点：名字是 DMIT-VPS，使用 VLESS、TCP 和 REALITY，并开启了 UDP 转发。

看到这三个英文词先别晕，它们不是三套互相打架的代理。

VLESS负责告诉服务器“我是谁、我要访问哪里”。

当前配置用一串叫 UUID 的编号识别用户。

TCP负责把数据可靠、按顺序送过去。

REALITY负责保护 Mac 到 DMIT 这一段连接。

所以三者只是各做一件事：VLESS 负责说清请求，TCP 负责运送，REALITY 负责保护。

至于某个网站该走直连还是 DMIT，那是 Clash 分流规则负责的另一层。

这套东西的准确叫法是：DMIT 上的 VLESS/REALITY 远程代理，加上 Mac 上 Clash 的流量接管。

日常把它简称“自建 VPN”大家也能听懂，但是排查问题时要用准确结构。

否则明明是 Clash 没接住流量，我们却跑去检查一套根本没使用的 VPN 配置，只会越查越乱。

这里有一个必须说清楚的边界。

当前只能确认 Mac 使用 VLESS + REALITY 连接这台 VPS，不能确认服务器里运行的到底是哪一个程序，也不能还原当初使用了哪条安装命令。

我尝试用现有 SSH 密钥只读登录，服务器拒绝了这把密钥。

要补全真实搭建过程，只能找到正确凭证，或者找回当时的安装脚本和记录。

在那之前，本章只写已经确认的结构，不拿猜测冒充实测。

节点配置不是服务器本身，而是一张连接说明书。

说明书里会写服务器地址、端口、连接方式、用户身份和安全参数。

Clash 读完以后，才知道该去哪里、敲哪扇门、用什么方式证明自己有权限。

远端服务器接到请求，再替 Mac 连接目标网站。

网站返回的数据，则沿着原来的路线送回来。

UUID 应该像密码一样保护。

服务器地址、端口、REALITY 公钥和 Short ID 都不是服务端私钥。

但它们和 UUID 组成完整节点配置后，别人拿到就能直接导入使用。

所以节点截图要整体脱敏，服务端私钥更不能公开。

访问 HTTPS 网站时，还会同时出现两层保护。

REALITY 保护的是 Mihomo 到 DMIT；网站自己的 HTTPS 保护的是浏览器到目标网站。

可以把它想成双层信封：DMIT 能打开外层代理信封，里面仍然装着网站的 HTTPS 密文。

在浏览器正常验证网站证书、设备没有安装用于解密流量的受信任根证书时，远程代理不能直接读到里面的账号密码和网页正文。

如果访问的是普通 HTTP 网站，就没有网站 HTTPS 这层保护。

一套自建出口想要以后能自己救回来，至少要留下这些资料：

购买账户和续费日期；
服务器地址、操作系统和登录方式；
服务端程序名称、版本和配置文件位置；
监听端口与防火墙规则；
客户端节点配置、重启方式和验证方法。

认证信息放进密码管理器，不要塞进公开的 Markdown 正文。

远端结构看懂以后，我们回到 Mac。

应用把请求交给 Clash 之前，还会经过 Wi‑Fi、局域网地址、路由器、DNS 和 macOS 代理设置。

这些东西，其实都藏在 Wi‑Fi 的“详细信息”里。

第四章：Mac 的 Wi‑Fi“详细信息”到底在告诉我什么

打开“系统设置 → Wi‑Fi → 当前网络右侧的详细信息”，左边会看到 TCP/IP、DNS、WINS、802.1X、代理和硬件。

第一次看确实很像六套不同的网络设置，其实它们只是在从不同角度描述当前这张 Wi‑Fi 连接。

先看 TCP/IP。

当前截图中，IPv4 使用 DHCP 自动配置。

DHCP说白了，就是路由器自动帮 Mac 填好上网需要的参数。

Mac 连上 Wi‑Fi 后，不需要你手写地址。

路由器会告诉它：你在家里使用哪个 IP、这个局域网有多大、离开家里以后先把数据交给谁。

下面这张图重点看 IP 地址、子网掩码、路由器和 IPv6 四行：

截图里的 IP 地址，是 Mac 在当前家庭局域网里的座位号，不是网站看到的公网出口。

子网掩码是用来划分局域网范围的。

初学阶段不用计算，只要知道它帮助 Mac 判断“目标就在家里，还是应该交给路由器”。

路由器这一栏显示的是默认网关。

Mac 不知道更具体路线时，就先把数据交给它。

IPv6 设为“自动”，表示系统会根据当前网络自动获取 IPv6 配置。

第一章已经分别记录过 IPv4 和 IPv6，这里继续沿用同一套检查就行。

再看 DNS 页面。

它显示 macOS 当前设置的系统 DNS 服务器。

浏览器或 Mihomo 自己处理 DNS 时，实际查询路线不只看这里。

注意，DNS 负责找地址，不负责决定网页最终从哪个出口出去。

Clash 接管以后，DNS 路线还会继续变化。

这里先保持原设置，不要为了修代理同时乱改 DNS，把一个问题变成三个问题。

代理页面，是 macOS 和 Clash 真正接上头的地方。

当前网页代理和安全网页代理都指向 127.0.0.1:7897。

127.0.0.1 表示“这台 Mac 自己”，7897 是 Clash 在本机打开的入口。

应用按照系统代理发出的请求，会先在电脑内部交给这个入口，再由 Clash 决定直连还是去 DMIT。

下面这张图只需要确认两个值：服务器是 127.0.0.1，端口是 7897。

看到 HTTP 和 HTTPS 代理都指向这个本地入口，就说明支持系统代理的应用已经知道“先去找 Clash”。

WINS 和 802.1X 与当前家庭代理问题无关，保持默认即可。

硬件页面里的 MAC 地址，只是网卡在本地网络中的标识，不是网站看到的公网出口。

“私有 Wi‑Fi 地址”改的也是这个本地标识，不会把公网出口变成住宅代理。

看到这里，可以把整页压缩成五句话：

IP 和子网掩码：我在当前局域网里是谁；
路由器：离开局域网先交给谁；
DNS：域名先去哪里查地址；
代理：支持系统代理的应用先把请求交给谁；
硬件和 802.1X：网卡身份以及怎样加入网络。

网络原本正常时，不要同时修改 DHCP、DNS、IPv6 和硬件地址。

一次只查一层，真的会省很多时间。

现在已经看到 macOS 会把一部分流量交给 127.0.0.1:7897。

但是为什么系统代理开着，有些 App 还是不听话？

为什么打开 TUN 以后，覆盖范围又突然变大了？

下一章就来拆这个最容易把人绕晕的问题。

第五章：Clash Verge 到底接管了什么

先做一个对照实验。

只打开系统代理，用浏览器访问测试页，然后去 Clash 的“连接”页面找这条请求。

再打开 TUN，用刚才没有进入 Clash 的软件重新测试。

这个实验能直接看出：有的软件会主动遵守系统代理，有的软件要依靠 TUN 才能被接住。

顺便把三个角色分开。

你看到和点击的是 Clash Verge；真正接收流量、匹配规则、连接 DMIT 的核心叫 Mihomo；节点则是一份告诉 Mihomo“远端服务器怎么连”的说明书。

当前配置同时开启了系统代理和 TUN。

它们都在解决同一个问题：怎样把应用的流量交给 Mihomo。

区别只在于接流量的方式不同。

系统代理像 macOS 贴出来的一张通知：需要代理的请求，请交到 127.0.0.1:7897。

支持这张通知的浏览器和 App 会主动照做。

不读取系统代理的软件，不会因为开关变蓝就自动换路线；有些命令行工具也只听自己的设置。

应用把请求交给本地代理软件时，常见的交接方式有 HTTP 代理和 SOCKS5。

HTTP 代理更贴近网页连接。

SOCKS5 更通用，应用会对它说：“请替我连接这个地址和端口。”

SOCKS5 自身不等于加密。

在当前电脑上，它只负责“应用到本地 Mihomo”这一小段；Mihomo 到 DMIT 的远程连接，仍然使用第三章讲过的 VLESS + REALITY。

TUN 像 Clash 在 Mac 里创建的一张虚拟网卡。

系统把符合路线要求的数据先送进这张网卡，再由 Mihomo 处理。

因为它不需要每个 App 主动配合，所以能接住更多不读取系统代理的软件。

不过，TUN 打开也不等于所有通信百分之百进入 Clash。

局域网通信、被排除的路线、其他网络工具和已经建立的旧连接，仍要去“连接”页面确认。

Clash 首页还有规则、全局和直连三个模式。

它们不是三种新的接管方法，而是在回答另一个问题：流量已经进入 Mihomo 以后，该从哪个出口离开？

**规则模式：**从上到下检查规则，按照匹配结果走 DIRECT、PROXY 或其他策略组。

**全局模式：**不再用普通分流规则区分网站，已经接住的请求统一交给全局策略。

**直连模式：**已经接住的请求直接访问目标，不使用远程节点。

所以“全局模式”并不能证明整台电脑的每一项通信都已进入 Clash。

正确顺序永远是先问：这项流量有没有被系统代理或 TUN 接住？

接住以后，再问它选了哪条路线。

很多软件看起来“不受全局模式控制”，问题就卡在第一步——它压根没进 Clash。

当前配置使用 Rule，也就是规则模式。

它会先让腾讯和微信相关域名直连，再让中国 IP 直连，最后把没有匹配上的请求交给 PROXY 组。

这个组当前选中的是 DMIT-VPS。

说白了，现在不是“一切都走 VPS”，而是“明确的国内与腾讯流量先直连，其余再交给 DMIT”。

下面这张图重点看两个地方：顶部选中的是“规则”，PROXY 组当前选中的是 DMIT-VPS。

这张图只能证明当前选择，不能证明每个 App 都已经被接管。

是否真的经过 DMIT，仍然要看“连接”页面和实际出口。

当前 DNS 也交给了 Mihomo，并启用了 Fake-IP。

Fake-IP 可以理解成一个“临时取件号”。

Mihomo 先给应用一个只在本机使用的临时地址，同时记住它对应的真实域名。

应用拿着这个临时地址回来时，Mihomo 仍然知道它原本访问哪个网站，于是能更稳定地匹配域名规则。

这个临时地址不是网站真实 IP，也不会变成出口 IP。

某个软件没有走代理时，按这个顺序查：

先看 Clash“连接”页面里有没有它的请求。
完全没有，就查系统代理和 TUN 有没有接住。
已经出现，就看它命中了哪条规则、选了哪个出口。
最后再分别核对 IPv4、IPv6 和旧连接。

不要一上来就换节点。

流量根本没进入 Mihomo 时，换多少远端节点都不会生效。

到这里，我们已经能回答“Clash 有没有接住这项流量”。

接下来再看另一个经常被混淆的问题：抓取视频、公众号文章或访问网站前切换节点，电脑上到底改了什么？

第六章：切换代理后，电脑上什么变了，什么没变

在 Clash 里切换节点，电脑并没有“搬到美国”。

真正变化的，是进入 Clash 的新连接从哪里出去。

选中 DMIT 后，新连接先去 DMIT，再由 DMIT 访问网站；Mac、家庭 Wi‑Fi 和路由器都没有跟着改变。

先看哪些东西会变，哪些不会变：

项目	切换节点后会怎样
网站看到的出口 IPv4/IPv6	新连接经过新节点时随出口变化；没有进入 Clash 的连接仍使用原出口
出口地区和 ASN	随新出口网络变化
Mac 的局域网 IP、Wi‑Fi 和路由器	不会因为切节点自动变化
Cookie、登录状态和本地文件	不会自动清空或迁移
浏览器语言、时区、屏幕、设备信息	不会自动跟随出口地区变化
已经建立的连接	应用继续复用旧连接时，仍沿原路线传输；建立新连接后才使用新路线
DNS 路径	由当前 DNS 与 TUN 配置决定，不能只凭节点名称判断

这里最容易踩坑的是旧连接。

浏览器为了省时间，会重复使用已经建立的连接。

只要应用还在复用旧连接，数据就继续沿旧路线走；应用建立新连接后，才会按照刚选的节点重新出发。

所以切完节点后，不要只刷新一个已经打开很久的页面。

关闭旧页面或重启测试应用，再发起一次新请求，然后去 Clash 的“连接”页面核对。

切节点也不会清空 Cookie、登录状态和浏览器记录。

Cookie 可以先理解成网站留在浏览器里的“小纸条”，用来记住登录和偏好。

换出口不会自动撕掉这些纸条，也不会自动修改系统语言、时区和设备信息。

这不代表某一项不同就一定导致封号。

准确的结论只有一个：切换节点只改变网络路线，不会把整套设备环境一起改掉。

抓取视频或文章时，还要先问一句：真正发出下载请求的是谁？

常见情况有三种：

浏览器自己请求内容，路线取决于浏览器有没有进入 Clash。
本地抓取工具重新下载内容，路线取决于这个工具有没有进入系统代理或 TUN。
云端服务替你下载，目标网站看到的是云端服务的出口，不是这台 Mac 的出口。

所以，在浏览器里复制了一个链接，不代表后面的抓取也沿用浏览器路线。

视频号或公众号工具也是同样的判断方法。

当前规则把腾讯和微信相关域名设为 DIRECT，这些请求进入 Clash 后会直接使用本地网络，不经过 DMIT。

课程这里只检查网络路径，不操作微信。

验证时看 Clash 连接记录里的进程、目标域名、命中规则和出口，不能用“工具运行成功”反推它一定走了代理。

还要单独检查 IPv4 和 IPv6。

如果 IPv4 查询结果来自 DMIT，而 IPv6 来自本地运营商，结论很明确：两套连接没有走同一个出口。

这时按顺序查三件事：IPv6 请求有没有出现在 Clash 连接页、出现后命中了哪条规则、远程节点能不能正常完成这类连接。

每次切换节点，可以照着下面做：

记录切换前的 IPv4、IPv6、地区和 ASN。
选择新节点。
关闭旧页面或重启测试应用，让它建立新连接。
重新查询 IPv4、IPv6、地区和 ASN。
在 Clash 连接页找到这次请求，确认命中的规则和实际出口。
最后再运行真正要用的工具。

这样一来，“切了节点却没生效”就不再是玄学。

问题只会落在接管、规则、节点、旧连接或 IPv4/IPv6 其中一层。

手动切换适合测试，不适合每天靠记忆维持路线。

下一章直接把需求写成规则：哪些网站必须直连，哪些网站必须走 DMIT。

第七章：把“我想怎么走”写成可验证的分流规则

分流没有想象中那么复杂。

说白了，就是提前告诉 Clash：这个网站直连，那个网站走 DMIT，广告直接拦住。

请求进入 Clash 后，规则会从上往下检查。

对本章使用的域名和 IP 规则来说，只要选中的节点支持这项流量，第一条有效匹配就会决定出口。

当前 DMIT-VPS 已开启 UDP 转发。

换成不支持 UDP 的节点后，UDP 请求会继续向下匹配；这不影响本章当前配置的判断。

所以越具体的规则越要放在前面，负责“其他情况”的兜底规则放在最后。

先别急着写配置。

把真实需求写成人话：

家庭局域网、腾讯与微信域名，以及目标 IP 命中中国地理库的连接：直接使用本地网络。
Claude 或其他指定服务：只走 DMIT-VPS。
普通海外网站：进入可以手动选择的 PROXY 组。
广告或明确不允许访问的目标：直接拒绝。
前面都没说到的流量：交给最后一条兜底规则。

第五章已经讲过，DIRECT 是直连，PROXY 是一个装着多个出口选项的策略组。

这里新增一个 REJECT，意思是直接拒绝连接。

当前 PROXY 组里同时有 DMIT-VPS 和 DIRECT。

所以“现在选中了 DMIT”不等于“这个网站永远只能走 DMIT”。

以后手动切换这个组，路线仍会跟着变。

如果一个网站必须使用固定出口，而且 DMIT 断开时宁可打不开，也不能偷偷回到本地网络，就要单独建一个只放 DMIT-VPS 的组。

下面这段先用来读懂结构，不要直接复制。

真实域名要以 Clash 连接记录为准：

proxy-groups:
  - name: DMIT-ONLY
    type: select
    proxies:
      - DMIT-VPS
 
rules:
  - DOMAIN-SUFFIX,claude.ai,DMIT-ONLY
  - DOMAIN-SUFFIX,anthropic.com,DMIT-ONLY
  - GEOSITE,tencent,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,cn,DIRECT
  - MATCH,PROXY

这几行可以一条一条看：

DOMAIN-SUFFIX,claude.ai：claude.ai 和它下面的子域名都走 DMIT-ONLY。
GEOSITE,tencent：腾讯相关域名直连。
GEOSITE,cn：规则库里的中国域名直连。
GEOIP,cn：目标 IP 属于中国时直连。
MATCH：前面都没匹配到的请求，交给 PROXY。

一个网站不只请求首页。

正确做法是正常访问一次，再打开 Clash 的“连接”页面，把这次访问实际出现的域名逐个核对。

只有确实属于该服务的域名，才加入固定出口规则。

除了按网站分流，Mihomo 也能按应用进程分流。

但进程名会受到系统和软件打包方式影响。

域名规则能解决时，先用域名；只有一个程序会访问大量、难以逐个列出的地址时，再考虑进程规则。

这里再把前面最容易绕晕的 SOCKS5 和 DNS 说清楚。

SOCKS5 负责把请求交给 Clash，DNS 负责把网站名查成地址，分流规则负责选择出口。

三者各做一件事，不是三种代理。

假设一个 App 要访问 example.com。

它交请求时有两种说法：

直接告诉 Clash：“我要访问 example.com。”
App 自己先查出 IP，再告诉 Clash：“我要访问这个数字地址。”

就像打车时，一种是告诉司机“去某某店”，另一种是只报一串门牌号。

Clash 拿到网站名字时，可以直接匹配域名规则。

Clash 只拿到数字 IP 时，就要检查 IP 规则，或者查看 Fake-IP 有没有保存“这个 IP 原来对应哪个域名”的关系。

现阶段不用研究 DNS 的所有模式。

规则没命中时，先打开“连接”页面。

目标显示网站名字，就查域名规则；只显示数字 IP，就查 IP 规则和 DNS/Fake-IP 设置。

规则能保存，不代表结果已经正确。

每改一小处，都要做一次验证：

修改前先复制当前有效配置，另存一份备份。
访问一个已经在当前连接记录中确认直连的目标，检查它是否命中 DIRECT。
访问一个必须固定出口的网站，确认命中 DMIT-ONLY。
访问一个普通海外网站，确认进入 PROXY。
再查询出口 IP，确认结果和规则一致。

DMIT-ONLY 里只放 DMIT-VPS，不放 DIRECT 和其他节点。

这样 DMIT 断开后，请求会失败，不会自动从本地网络出去。

这只约束已经进入 Clash 并命中 DMIT-ONLY 的连接。

网站遗漏的关联域名、没有被接管的流量、DNS 和 IPv6，仍然要分别验证。

验证失败时就恢复备份。

不要同时改 TUN、DNS、节点和几十条规则，否则出了问题，你连是哪一步改坏的都找不到。

做到这里，路线就不再依赖你每天手动切节点。

接下来要解决的是另一个现实问题：Mac 和手机分别该用什么客户端，才接得住同一套节点和分流规则？

第八章：怎样给电脑和手机选择客户端

先把一个误区拿掉：换客户端，不等于换出口。

客户端只是设备上的“交通指挥员”。

它负责接收流量、执行规则，再连接 DMIT。

真正决定网站看到哪个出口的，仍然是最终选中的远程节点。

同一份节点能不能换到另一个客户端，取决于新软件能不能读懂当前的 VLESS + REALITY 参数。

对这台 Mac，现阶段最省事的做法是继续使用已经跑通的 Clash Verge。

它已经能使用当前节点，也能处理系统代理、TUN、DNS 和规则分流。

再装一套同类软件，不会让网络自动变快，反而会多出一套端口、路由和 DNS 设置。

当前 Mac 安装的是 Clash Verge 2.4.4。

以后升级前，先备份配置，再查看官方发布说明；教程不写一个很快就会过期的“最新版”数字。

手机端暂时不能只凭“V2RayX”这个口述名称下结论。

这次没有连接手机，也没有核对操作系统、App 全名和版本。

下一次检查手机时，先打开应用商店或设置页，记录这四项，再决定要不要迁移。

选择手机客户端时，不看名字有多炫，先检查四件事：

能不能导入当前 VLESS + REALITY 节点。
能不能接管手机系统流量。
能不能按照规则分流。
能不能分别检查 IPv4、IPv6 和 DNS。

四项都满足，再看软件是否持续维护、下载来源是否可信。

界面好看、节点多、别人推荐，都不能代替这四项检查。

同一台设备不要同时开启两个代理客户端。

两边会争抢系统代理、TUN 路由和 DNS。

你看到甲软件显示“已连接”，实际流量却从乙软件的旧端口出去，排查会非常痛苦。

迁移时先备份旧配置，再关闭旧客户端的系统代理和 TUN，然后测试新客户端。

确认新客户端能独立完成全部测试后，再决定旧软件是否继续保留。

这里不靠删除应用解决冲突。

任何删除操作都要单独确认。

电脑和手机的界面不需要一样，但最终结果要一样：

腾讯与微信域名，以及目标 IP 命中中国地理库的连接直连。
指定服务的相关连接全部进入 Clash，并命中固定 DMIT 组。
DMIT 断开时，已经命中固定组的连接不会回退直连。
IPv4 和 IPv6 都符合预期。

用同一组网站在两台设备上测试，比背客户端名字更可靠。

客户端选好以后，节点还可以来自两种地方：自己维护的 DMIT，或者机场提供的订阅。

下一章就看这两条路线到底有什么区别。

第九章：机场和自建 VPS，究竟谁更稳定

先说结论：机场和自建 VPS，没有一个在所有情况下都更稳定。

它们最大的区别，不是协议名字，而是谁在维护服务器、流量经过几层、出问题后谁来修。

“机场”不是正式技术名词。

它是中文用户对代理服务商的俗称。

服务商维护一批服务器，把连接信息做成节点，再通过订阅链接发给用户。

用户付费后直接使用，不需要自己维护每台服务器。

自建 VPS 则相反。

服务器是自己买的，服务端是自己部署的，认证参数、续费和故障也由自己负责。

当前这条 DMIT 路线很简单：Mac 直接连接洛杉矶 VPS，VPS 再替 Mac 访问网站。

机场则常见两种结构：直连和中转。

自建或机场直连：设备 → 最终出口 → 网站
 
机场中转：设备 → 入口服务器 → 出口服务器 → 网站

直连还是中转，不看互联网路由器的数量。

直连时，客户端直接连接最终出口。

中转时，客户端先连接一台独立入口服务器，再由服务商把数据转发到最终出口。

公网还是专线，看入口到出口之间走什么线路。

因此，“专线”本身既不是直连，也不是中转。

服务商采用“入口服务器 → 受管理线路 → 出口服务器”这套结构时，它属于专线中转。

“专线节点”没有统一的商品标准。

节点名字写着专线，只能说明服务商这样命名，不能证明底层用了哪一种线路。

真正判断时，要看服务商公布的入口和出口、实际路由，以及晚高峰表现。

所以问“谁更稳定”时，要拆成五个问题：

稳定维度	自建 VPS	机场
出口 IP 稳定	单台实例存续期间容易保持一致	由服务商调度，是否更换或共享由服务商决定
线路稳定	依赖本地到单个机房的路线	由入口、中转、出口、负载和运营质量共同决定
节点冗余	当前 DMIT 只有一个主节点，属于单点故障	套餐含多个可用节点时，故障后可以切换
维护稳定	用户负责续费、服务、密钥或安全参数、端口和故障；所选协议需要证书时才维护证书	服务商负责，但用户依赖其运营能力
账号环境连续性	容易固定使用一个出口	手动或自动切节点容易改变地区和 ASN

自建的优势是出口和配置更可控。

同一台 VPS 长期运行时，出口更容易保持一致。

但它也只有一个主要节点：服务器停机、线路故障或流量用尽，这条路线就断了，而且要自己修。

机场的优势是节点多，坏了一条可以换另一条。

服务商也能安排入口、中转和多地区出口。

但机场用户多、出口常被共享，节点和 IP 由服务商调整。

服务商超售、维护不及时或停止运营，用户没有控制权。

自建也不等于隐身。

DMIT 掌握服务器账户信息，也能在基础设施层观察网络连接的元数据。

服务端是否保存目标连接日志，取决于服务器里的代理程序和日志配置。

目标网站能看到出口 IP。

使用机场时，还要再信任机场运营者和它提供的节点。

HTTPS 能保护浏览器与网站之间的正文内容，但不会隐藏出口 IP，也不会让整条网络路线消失。

结合当前需求，DMIT 更适合承担“固定出口”和“自定义分流”。

经过验证的机场可以用作普通浏览或故障备用，但不要让它自动接管那些必须保持固定出口的服务。

这个选择只适用于当前用途。

DMIT 到本地线路长期丢包时，要重新选机房或线路；目标平台不接受该数据中心网络时，要重新评估出口类型。

不要因为它叫“自建”就坚持使用，也不要因为机场节点多就默认它更稳。

线路稳定只解决“能不能稳定到达网站”，不代表平台一定接受账号。

最后一章就用 Claude 把网络问题、地区政策和账号限制分开。

第十章：Claude 出问题时，怎样区分网络、地区政策和账号限制

Claude 打不开，不等于账号已经被封。

这里至少有三种情况：网络根本没有到达 Claude、Claude 拒绝了这次请求、账号本身受到限制。

三种问题的处理方法完全不同。

先看官方已经说清楚的部分。

Anthropic 的申诉说明列出了几类封禁原因：重复违反 Usage Policy、从不支持的地区创建账号，以及违反服务条款。

截至 2026 年 7 月 19 日核验时，Anthropic 在 2026 年 3 月 16 日更新的Claude 可用地区列表中没有列出中国大陆。

这是平台政策条件，不是改一条 DNS 或换一个节点就能改变的网络故障。

本教程只解释网络状态和排障方法，不提供绕过地区限制的方案。

再看官方没有公开的部分。

截至本教程核验日，在检查到的 Anthropic 公开官方材料中，没有看到完整的账号风控算法，也没有看到“使用某一种代理或某一个 VPS IP 就一定封号”的结论。

所以，只查一次出口 IP，不能反推出账号被停用的唯一原因。

在同一批公开官方材料中，也没有看到把 ASN、语言、时区和 DNS 路径写成固定封号公式。

真正排查时，按四步来：

先看 Mac 能不能正常上网。 普通网站也打不开，就检查 Wi‑Fi、DNS，以及 Clash 有没有接住请求。
再看 Claude 走了哪条路线。 在 Clash“连接”页面确认它命中了 DIRECT、DMIT-ONLY 还是其他策略，再核对节点、IPv4、IPv6、地区和 ASN。
再看网站返回了什么。 403 表示链路中的某个 HTTP 服务拒绝了请求；429 表示触发限流或配额；5xx 表示处理请求的服务一侧发生错误。状态码只说明本次响应，不能单独证明账号为什么被封。
最后处理账号和政策。 页面明确显示账号被停用时，保存提示页面、发生时间、当时的出口结果和 Clash 日志，再通过官方申诉入口申请复核。

这套顺序的重点，是一次只排除一层。

Clash 里完全没有 Claude 请求，就先查系统代理或 TUN。

网页能打开，但账号明确被停用，就转去看官方政策和申诉，不要继续反复改 DNS、换节点。

把错误提示、时间、出口结果和 Clash 日志放在一起，才能留下可以复查的证据。

把十章收成一份个人网络操作手册

学完以后，真正要留下的不是一份网络词典，而是六份以后能救命的资料：

当前网络路线图。
DMIT 套餐、续费日期和服务器信息。
服务端的部署与恢复记录。
Mac 和 Clash 的脱敏配置备份。
分流需求、规则和测试结果。
每次故障的时间、截图和排查记录。

前一章留下的结果，会成为后一章的起点。

概念也都嵌在真实问题里，不需要再单独做一本词典。

已经确认的部分：

Mac 使用 Clash Verge 2.4.4 与 Mihomo。
系统代理指向本机 7897 端口。
TUN、Fake-IP DNS 和 Rule 模式已经开启。
腾讯、微信相关域名和中国 IP 优先直连。
其他流量进入当前选中 DMIT-VPS 的 PROXY 组。
远程节点使用 VLESS over TCP + REALITY。
DMIT 实例为洛杉矶 AN5 Premium TINY 规格。

还没有确认的部分：

VPS 服务端具体运行哪个程序。
当初使用哪条脚本和命令完成部署。
手机端“V2RayX”的准确 App 名称、版本和核心。
手机能不能完整复现当前分流结果。
需要服务器凭证或手机设备才能完成的实测项。

这份教程还有两项实操没有闭环。

第一，拿到正确凭证后，只读核验 VPS 服务端，把第三章补成真正可恢复的部署记录。

第二，核对手机系统、App 全名和版本，把第八章补成电脑和手机使用同一套分流的实测结果。

以后继续完善，也沿着这两项真实任务往下走。

只有操作遇到新概念时，再把它补进对应章节，不额外增加一篇协议百科。

逸尘的AI知识库

探索

从买DMIT到Clash分流：我的网络实战完整教程