dmit 使用

Posted on Edited on In ,

购买与登录

这次买的是 DMIT 洛杉矶 LAX.AS3.Pro.Pocket，系统为 Debian 13。安装前先确认 Mac 可以通过 SSH 登录 VPS：

1
ssh dmit

这里的 dmit 是我在 Mac 的 ~/.ssh/config 中设置的 Host 别名。公钥放在 DMIT 实例上，登录时使用 Mac 上对应的私钥。不要把私钥写进文章或发给别人。

安装 3x-ui

2026-09-24 安装时，3x-ui 的稳定版为 v3.8.5。在已经登录的 VPS 终端下载并执行该版本的官方安装脚本：

1
2
curl -fLsS -o /root/install-3x-ui-v3.8.5.sh https://raw.githubusercontent.com/mhsanaei/3x-ui/v3.8.5/install.sh
bash /root/install-3x-ui-v3.8.5.sh v3.8.5

安装器里的选择是：数据库用默认的 SQLite；不自定义面板端口，让它生成随机端口；SSL 选 4. Skip SSL；随后在「Bind the panel to 127.0.0.1 only?」回答 y。这组选择的前提是只通过 SSH 转发打开管理面板。面板监听 VPS 的 127.0.0.1，不接受公网直连。官方的面板设置说明 也明确要求：没有 TLS 时，不能把明文 HTTP 面板暴露到公网。

安装完成后，systemctl is-active x-ui 应返回 active。本次验证中，面板只监听 VPS 的 127.0.0.1；从 Mac 经 SSH 转发访问登录页返回 HTTP 200。安装器默认还启动独立的订阅服务，监听公网 2096 端口。本机暂时用不到订阅，我已将它关闭；未来要使用订阅，再在面板的 Subscription 设置里启用并配置安全访问。官方订阅说明

为什么在本机浏览器打开

127.0.0.1 总是指「当前这台机器」。浏览器地址里的 127.0.0.1:2222 是 Mac；3x-ui 监听的 127.0.0.1:60925 是 VPS。它们是两个不同的本机地址。

1
2
3
Mac 浏览器 → Mac 127.0.0.1:2222
             → SSH 加密连接 → VPS 公网 22 端口
             → VPS 上的 sshd → VPS 127.0.0.1:60925 → 3x-ui

ssh -L 让 Mac 上的 SSH 客户端监听 2222，再通过已建立的 SSH 连接把请求交给 VPS 的 sshd。sshd 从 VPS 内部连接面板的 60925。-N 表示只转发连接，不打开远程命令行。面板网页虽然显示 http://，但它在两端都只经过本机回环地址；跨公网的部分包在 SSH 加密连接里。SSH 断开后，Mac 上的转发入口就消失，VPS 上的 3x-ui 仍继续运行。

这不等于「没有公网端口」。目前 VPS 的 22 端口供 SSH 登录和转发，8443 端口供 Mac 的代理客户端连接；两者都对公网监听。面板的 60925 只监听 VPS 本机，Mac 的 2222 也只监听 Mac 本机。安装后默认监听公网的订阅端口 2096 已关闭。手机上的 127.0.0.1 也只指手机，不能直接拿 Mac 的本地面板地址访问。

安装器生成的用户名、密码、端口和随机路径保存在 VPS 的 /etc/x-ui/install-result.env，文件权限为 600。在自己的 Mac 终端查看所需字段，不要把输出贴到聊天或文章里：

1
ssh dmit "grep -E '^XUI_(USERNAME|PASSWORD|PANEL_PORT|WEB_BASE_PATH)=' /etc/x-ui/install-result.env"

记下 XUI_PANEL_PORT 后，在 Mac 另开一个终端执行。本机这次随机到了 60925；其他实例要换成各自的端口。

1
ssh -N -L 127.0.0.1:2222:127.0.0.1:60925 dmit

保持转发终端运行，然后打开 http://127.0.0.1:2222/<XUI_WEB_BASE_PATH>/，用刚才查到的账号密码登录。127.0.0.1 是 Mac 自己，不是 VPS 的公网地址；浏览器到 VPS 的这段连接由 SSH 加密。如果已有转发占用 2222，不用重复运行命令。首次登录后可在面板中启用两步验证。

网上那篇 DMIT 教程的官方安装命令仍可用，但它建议证书失败后开放固定的 10000 端口，用公网 HTTP 登录面板。我没有照做。固定高位端口也挡不住扫描；面板始终只通过 SSH 转发访问。

3x-ui 和 Clash Verge 怎样配合

3x-ui 是管理 Xray 的网页。它的后台用 Go 写，网页用 React 和 TypeScript 写；你在网页里添加入站和客户端，设置保存在 VPS 的 SQLite 数据库中。3x-ui 再把设置交给 Xray。真正接收 Mac 连接、向网站发请求的是 Xray。VPS 上的 x-ui 服务由 systemd 管理；关掉 Mac 上的面板网页，不会停止已经运行的代理。3x-ui 官方架构说明

上面通过 SSH 打开面板，是为了管理服务器。平时 Mac 上网时，Clash Verge 把连接交给内置的 Mihomo：它按规则挑出需要走代理的请求，用 Shadowsocks 2022 加密后发往 VPS 公网的 8443 端口。Xray 验证客户端密码，再替 Mac 连接网站；网站返回的数据沿原路送回。Clash Verge 可以通过系统代理或 TUN 接收应用流量，取决于 Mac 上启用的模式。Mihomo 的 Shadowsocks 配置说明 · TUN 说明

1
[Mac app] -> [Clash Verge / Mihomo] == Shadowsocks 2022 :8443 ==> [DMIT / Xray] -> [Website]

走这条代理连接时，网站通常看到 DMIT 的公网 IP。如果网站本身使用 HTTPS，Mac 应用到网站的 HTTPS 加密仍然存在；Shadowsocks 保护的是 Mac 到 VPS 这一段。VPS 需要知道请求要发往哪里，所以这套连接也不等于完全匿名。

这里有三种不同的凭据：SSH 私钥用于登录 VPS，3x-ui 账号密码用于登录面板，Shadowsocks 客户端密码用于让 Mihomo 连接 Xray。以后给 iPhone 配置时，单独添加一个客户端，就能分别停用 Mac 和 iPhone 的连接。

Mac 上使用 Clash Verge

Mac 安装的是 Clash Verge Rev 2.5.5。起初创建了 VLESS + REALITY 入站，但它自带的 Mihomo 内核报 REALITY authentication failed；同一节点用 Xray 客户端则能连通。3x-ui 上游也有相近的兼容问题记录。本次没有通过降低安全检查或降级 Xray 核心来绕过它，而是改建为一个仅供自己使用的 Shadowsocks 2022 入站，方法是 2022-blake3-aes-256-gcm，Mac 使用单独的客户端密钥。3x-ui 管理面板仍在本机回环地址，订阅服务 2096 仍关闭。

第二个现象是端口。Mac 物理网卡直连 DMIT：SSH 的 22 端口约 0.18 秒建立连接，最初的节点端口 443 超时；临时探测 8443 约 0.19 秒连通。把节点迁到 8443 后，用绑定 Mac 物理网卡的独立 Mihomo 进程访问网页，返回 HTTP 200，出口 IP 是 DMIT。

随后复测又发现：443 没有服务监听时，连接请求能到达 VPS 并收到拒绝；换成临时测试监听器时，Mac 约 0.17 秒连通。再把同一个 Shadowsocks 2022 节点短暂迁回 443，完整网页请求也返回 HTTP 200，之后已恢复 8443。所以不能把首次超时解释成「443 被永久封锁」，也不能仅凭这些结果断定是运营商、跨境网络还是服务商造成的。8443 是这次实测稳定连通后的当前选择，长期表现仍需观察。

已经把这份配置作为单独的「DMIT 自建 Mac」本地配置导入 Clash Verge。短暂启用它时，节点测速约 194 ms，实际网页请求也返回 DMIT 出口 IP；验证后已切回原订阅。要使用它，在 Clash Verge 的「订阅」页对「DMIT 自建 Mac」点右键，选「使用」；切回原订阅用同样方法。这个连接由 Clash Verge 直接访问 VPS 的 8443，不依赖管理面板的 SSH 转发窗口。

连接密钥存在 Mac 的本地配置中，文件权限已设为仅当前用户可读；不要把 YAML 内容、分享链接或二维码提交到博客或发给别人。iPhone 后续应单独建一组客户端密钥，方便分别停用。当前测速只证明这台 Mac 在当时的网络下可用，不保证别的运营商或时段表现相同。

Mac 国内直连、其他走 DMIT

最初的 DMIT 配置只有 MATCH,PROXY，所以百度等国内网站也走美国服务器。后来按 Loyalsoldier/clash-rules 的白名单模式加入五份规则：私有域名与局域网地址直连，已知需代理域名走 DMIT，直连域名和中国大陆 IP 直连，剩余流量仍走 DMIT。这里的 “ 白名单 “ 指网站分流，与全局脚本里筛选国家节点的 AutoTest-White 无关。

该仓库的文件虽然以 .txt 结尾，内容却是 payload: 开头的 YAML，因此 format 使用 yaml。规则每天通过 PROXY 组更新一次；PROXY 在这份配置中选的是 DMIT-US-Mac。Mihomo 规则提供者说明

Clash Verge 的「规则」页只列出 ls_private、ls_direct 等规则集入口，不会把集内的每个域名逐条展开。本次下载的 dmit-ls-direct.yaml 含有 +.baidu.com；运行日志也显示百度相关请求命中 RuleSet(ls_direct) 并走 DIRECT。

DMIT 配置带有 x-global-script-default-exit: PROXY。Clash Verge 的全局脚本软链接指向 vault/clashx/1_all.js：启用 DMIT 时，脚本把个人规则加在下面的规则集前面，也加入两个 AWS 节点、AWS-VPC 组和「🌈地区规则默认出口」手动选择组。个人规则中的 HK、TW、US、JP 都指向这个手动组；它默认选 PROXY，即当前选中的 DMIT 节点。也可以在组里手动改选其他节点。两条公司内网专用规则仍指向 AWS-VPC。这份配置不创建可能筛不到节点的自动测速组。PROXY 仍只有 DMIT 和 DIRECT 两个选项，所以地区规则的默认代理出口是 DMIT。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
rule-providers:
  ls_private:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/private.txt"
    path: ./ruleset/dmit-ls-private.yaml
    interval: 86400
    proxy: PROXY
  ls_lancidr:
    type: http
    behavior: ipcidr
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/lancidr.txt"
    path: ./ruleset/dmit-ls-lancidr.yaml
    interval: 86400
    proxy: PROXY
  ls_proxy:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt"
    path: ./ruleset/dmit-ls-proxy.yaml
    interval: 86400
    proxy: PROXY
  ls_direct:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/direct.txt"
    path: ./ruleset/dmit-ls-direct.yaml
    interval: 86400
    proxy: PROXY
  ls_cncidr:
    type: http
    behavior: ipcidr
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/cncidr.txt"
    path: ./ruleset/dmit-ls-cncidr.yaml
    interval: 86400
    proxy: PROXY

rules:
  - RULE-SET,ls_private,DIRECT
  - RULE-SET,ls_lancidr,DIRECT,no-resolve
  - RULE-SET,ls_proxy,PROXY
  - RULE-SET,ls_direct,DIRECT
  - RULE-SET,ls_cncidr,DIRECT
  - MATCH,PROXY

本次没有添加广告拦截规则。当前配置有 54 条规则、3 个节点和 3 个策略组。「🌈地区规则默认出口」默认选择 PROXY，再由 PROXY 选择 DMIT。Clash Verge 实际监听本地 7897 端口；原 YAML 中的 mixed-port: 18791 会被应用运行时配置覆盖，不能把 18791 当作当前可用的本地代理端口。

排查海外连接失败：先确认测试内核已启动完成

2026-09-25 排查时，先确认运行中的订阅确实是 DMIT，再分别通过本地 7897 代理和 TUN 请求百度、api.ipify.org、Google 的 generate_204：六次请求全部成功，返回 200 或 204。DMIT 服务器上的 x-ui 服务正常，8443 正在监听；服务器直接访问两个海外测试地址也成功。

随后复现了临时测试方法的问题：Mihomo 的管理接口已经能响应时，五份规则集可能还没加载完成，此时发起 HTTPS 请求会报连接重置或 SSL_ERROR_SYSCALL。连续三次启动对照中，过早请求失败 3/3；同一个进程等待规则集加载完成后再请求，成功 3/3，出口都是 DMIT，耗时约 0.64 秒。这里没有改节点、密码或服务器，只改变了发起测试的时机。

以后单独启动测试内核时，应检查 /providers/rules 中五个规则集的 ruleCount 都大于零，再确认代理能完成实际 HTTPS 请求。管理接口可访问、代理端口已监听，或者固定等待半秒，都不足以单独证明代理已就绪。本轮也排除了 “ 必须改 DNS 才能让这些测试请求成功 “ 的判断：保持原 DNS 配置，等待初始化完成后即可成功。

这确认了临时测试会产生假失败；本轮没有复现日常使用中的海外超时，也不能据此解释每一次历史断网或保证全天稳定。若实际浏览器再次失败，应记录具体网站、时间、当时选中的订阅与策略组，再对照客户端日志和服务器连通性，避免把临时测试的失败直接归因于 DMIT。

iPhone：在 Quantumult X 中新增 DMIT 节点

Quantumult X 官方示例已包含 2022-blake3-aes-256-gcm，与目前 DMIT 节点使用的方法一致。官方配置示例

手机已有可用配置时，只需在 QuanX 中扫码添加 DMIT-US 本地节点，再把它加入现有代理策略组并选中。原有手机分流规则继续生效；Mac 的 YAML、1_all.js 和其中的进程规则不会随节点一起导入。先更新 QuanX，再测试手机实际连接。

私有导入文件保存在 Mac 的 ~/.config/dmit/：dmit-shared-node-qr.png 是节点二维码，quanx-dmit-shared-node.txt 是 QuanX 原生节点行，dmit-shared-node.ss.txt 是 SS 分享链接。这些文件含连接密钥，不应放入博客或公开仓库。二维码按 SIP002 的 AEAD-2022 要求编码，已在本地回读验证。

这次导出复用了 Mac 客户端的完整密钥，尚未创建手机独立客户端，也没有修改服务器。官方示例确认了加密方法支持；本机没有 Quantumult X，手机对当前完整节点参数的兼容性和实际联网仍需扫码后验证。以后如需单独统计或停用手机，再给手机分配独立客户端密钥。

参考资料