跳到主要内容

Mieru

Mieru(みえる,日语"看见"之意)是一种于 2021 年 10 月发布的代理协议,由开发者 @enfein 创建。它的设计目标是通过随机化填充和类随机数据流量外观,使代理流量在统计特征上难以与随机噪声区分,从而规避基于流量特征的深度包检测。

设计背景

Mieru 的设计针对一个具体的场景:在无法使用 TLS 伪装(如没有域名和证书)的情况下,如何让流量尽可能难以被识别。

其他协议的主要伪装策略:

  • Shadowsocks:自定义加密,流量看起来像随机数据,但协议头部有可识别特征
  • Trojan / VLESS + TLS:将流量伪装为 HTTPS,需要域名和证书
  • Hysteria 2 / TUIC:基于 QUIC,流量伪装为 HTTP/3,同样需要域名

Mieru 的策略则不同:它不尝试将流量伪装为某种具体的已知协议,而是让流量在统计特征上接近"纯随机数据",使检测系统无法建立有效的特征库。

核心设计

随机化填充

Mieru 对每个数据包都进行随机长度的填充,使数据包大小在统计分布上没有固定规律。这与 Shadowsocks(固定的协议头部)和大多数基于 TLS 的协议(握手模式固定)形成对比。

Shadowsocks 数据包大小分布:
|---固定大小的 AEAD 头部---|---加密数据---|

Mieru 数据包大小分布:
|---随机填充---|---加密数据---|---随机填充---|
(填充长度每次不同,无规律)

随机填充使得基于数据包大小特征的流量分类变得困难——检测系统无法通过"这个端口上的流量数据包大小分布符合某协议特征"来识别 Mieru。

自有的 TCP / UDP 传输

Mieru 不依赖 TLS,也不使用 KCP,而是实现了自有的传输层,同时提供 TCP 和 UDP 两种模式(在配置的 protocol 字段中选择)。UDP 模式延迟通常更低,但由于需要更多次解密尝试,吞吐不一定优于 TCP;官方在多数场景下推荐使用 TCP 模式。

关于传输模式

Mieru 的 TCP 与 UDP 传输共享同一套密钥派生与加密机制,区别只在底层承载方式。当线路对 UDP 限速或封锁时可切换为 TCP 模式;UDP 可用时则可优先选择 UDP 以获得更低延迟。

端对端加密

Mieru 在应用层实现了独立的加密机制,不依赖 TLS。加密密钥从用户名和密码通过强密钥派生函数生成,连接双方无需交换任何可被截获的密钥信息。

无固定握手特征

Mieru 的连接建立过程没有固定长度或固定格式的握手数据包。即使是连接初始阶段的数据,也经过了与后续流量相同的随机化处理,消除了握手阶段的可识别特征。

工作原理

连接建立流程

客户端
|
| 1. 使用用户名 + 密码派生加密密钥(无需交换密钥)
| 2. 向服务端发起连接(TCP 或 UDP 传输)
| 3. 发送带随机填充的加密请求(含目标地址)
v
服务端
|
| 4. 使用相同的用户名 + 密码重新派生密钥
| 5. 解密并验证请求(密钥不匹配则丢弃)
| 6. 建立到目标的连接
v
目标服务器

由于密钥由双方独立派生,网络上传输的所有数据都经过加密,不存在明文交换密钥的握手过程——这也消除了握手阶段的协议特征暴露风险。

多用户支持

Mieru 服务端支持同时配置多个用户,每个用户有独立的用户名和密码。服务端通过尝试使用每个用户的派生密钥对接收到的数据进行解密来判断请求归属。

服务端接收数据包
|
| 尝试用户 1 的密钥解密
| → 成功 → 以用户 1 的身份处理请求
| 尝试用户 2 的密钥解密
| → 成功 → 以用户 2 的身份处理请求
| 所有密钥均失败
| → 丢弃数据包(无任何响应)

对于无效的连接请求(密钥不匹配),服务端默默丢弃,不返回任何错误信息,有效防止主动探测发现服务端的存在。

与其他协议的对比

对比维度MieruShadowsocks 2022Hysteria 2VLESS + Reality
传输层TCP / UDPTCPUDP(QUIC)TCP
流量伪装策略随机化数据随机化数据(AEAD)HTTP/3 伪装TLS 1.3 + Reality
是否需要域名
是否需要 TLS 证书
握手特征无固定特征有固定盐值结构标准 QUIC 握手TLS 1.3 握手
数据包大小随机化有(随机填充)有限有限
抗检测能力评估一般一般极强
高丢包性能一般一般极好(Brutal)一般
客户端支持广度有限广泛广泛广泛
部署复杂度

优缺点

优点缺点
无需域名和 TLS 证书,部署简单客户端支持范围较窄
随机填充使数据包大小分布无规律抗检测能力评估为"一般",在强力检测下仍有风险
无固定握手特征,不易通过握手识别UDP 模式在受限网络中不可用(可改用 TCP)
无效请求默默丢弃,防止主动探测UDP 流量在某些网络路径上可能被 QoS 限速
同时支持 TCP / UDP 两种传输模式社区规模小,文档资源有限
配置简单,单一二进制文件性能不如 Hysteria 2 的 Brutal 激进
支持多用户与主流大生态(Xray、Mihomo、sing-box)的集成有限

适用场景

推荐使用 Mieru 的场景:

  • 没有域名,也不想使用 VLESS + Reality 的复杂配置,但需要比 Shadowsocks 更好的流量混淆
  • 愿意接受有限的客户端支持,作为多协议方案中的一个补充
  • 线路丢包率较高,希望自有 UDP 传输提供比 TCP 更好的稳定性
  • 对协议有探索兴趣,希望了解非 TLS 路线的现代混淆设计

不推荐单独依赖 Mieru 的场景:

  • 需要在严格审查环境中长期稳定使用(此时应优先 VLESS + Reality 或 AnyTLS)
  • 需要在多种客户端(iOS、Android、桌面)上同时使用同一节点
  • 使用 iOS 主流客户端(Shadowrocket、Quantumult X 等不支持 Mieru)
  • UDP 被封锁的企业/校园网络
关于抗检测能力的评估

Mieru 的抗检测能力被社区评估为"一般",这意味着在常规环境下能够工作,但在强力的主动检测下仍有被识别的可能。如果你处于检测力度非常强的网络环境,应优先选择 VLESS + Reality 或 Hysteria 2。

服务端部署参考

前置条件

  • 一台公网 VPS,已开放指定 UDP 端口的防火墙规则
  • 服务器无需域名和 TLS 证书

安装 Mieru 服务端

从 GitHub Releases 下载预编译二进制文件:

# 访问 https://github.com/enfein/mieru/releases 获取最新版本

# 以 Linux amd64 为例
wget https://github.com/enfein/mieru/releases/latest/download/mita-linux-amd64.tar.gz
tar -xzf mita-linux-amd64.tar.gz
chmod +x mita
mv mita /usr/local/bin/

Mieru 服务端程序名为 mita,客户端程序名为 mieru

服务端配置

Mieru 使用 JSON 格式的配置文件。创建配置文件 /etc/mita/server_config.json

{
"portBindings": [
{
"portRange": "9000",
"protocol": "UDP"
}
],
"users": [
{
"name": "user1",
"password": "your-strong-password-1"
},
{
"name": "user2",
"password": "your-strong-password-2"
}
],
"loggingLevel": "DEFAULT"
}

配置字段说明:

字段说明
portBindings.portRange服务端监听端口,可以是单个端口(如 9000)或范围(如 9000-9010
portBindings.protocol传输协议,支持 UDPTCP(推荐 UDP)
users.name用户名,客户端配置中需要填写相同的值
users.password密码,客户端配置中需要填写相同的值
loggingLevel日志级别,可选 DEFAULTDEBUGINFOWARNERROR

使用端口范围可以在一定程度上对抗基于端口的封锁:

{
"portBindings": [
{
"portRange": "9000-9010",
"protocol": "UDP"
}
],
"users": [
{
"name": "user1",
"password": "your-strong-password"
}
]
}

应用配置并启动服务

# 应用服务端配置
mita apply config /etc/mita/server_config.json

# 启动 Mieru 服务端
mita start

# 检查运行状态
mita status

# 查看日志
mita get log

Systemd 服务单元

Mieru 有内置的 systemd 服务管理支持:

# 安装 systemd 服务
mita install

如果需要手动创建服务单元文件:

[Unit]
Description=Mieru Proxy Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mita run
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

开放防火墙规则

# 开放 UDP 端口(根据配置中的端口号修改)
ufw allow 9000/udp

# 如果使用端口范围
ufw allow 9000:9010/udp

管理用户

Mieru 支持在不重启服务的情况下动态更新配置:

# 修改配置文件后,重新应用配置
mita apply config /etc/mita/server_config.json

# 重启服务使新配置生效
mita stop
mita start

客户端使用

下载 Mieru 客户端

# 访问 https://github.com/enfein/mieru/releases

# Linux amd64 客户端
wget https://github.com/enfein/mieru/releases/latest/download/mieru-linux-amd64.tar.gz
tar -xzf mieru-linux-amd64.tar.gz
chmod +x mieru
mv mieru /usr/local/bin/

# Windows 客户端(下载 mieru-windows-amd64.zip)
# macOS 客户端(下载 mieru-darwin-amd64.tar.gz)

客户端配置文件

创建客户端配置文件(默认路径因系统而异,也可以通过 --config 指定):

{
"profiles": [
{
"profileName": "my-server",
"user": {
"name": "user1",
"password": "your-strong-password"
},
"servers": [
{
"ipAddress": "your.server.ip",
"portBindings": [
{
"portRange": "9000",
"protocol": "UDP"
}
]
}
]
}
],
"activeProfile": "my-server",
"rpcPort": 8964,
"socks5Port": 1080,
"loggingLevel": "DEFAULT"
}

配置字段说明:

字段说明
profiles服务器配置列表,可以配置多个服务器
profileName配置名称,便于区分多个服务器
user.name用户名,必须与服务端配置一致
user.password密码,必须与服务端配置一致
servers.ipAddress服务器 IP 地址(或域名)
servers.portBindings服务端监听的端口,需与服务端配置一致
activeProfile当前激活的服务器配置名称
socks5Port本地 SOCKS5 代理监听端口
rpcPort客户端 RPC 管理端口(内部使用,无需对外开放)

应用配置并启动客户端

# 应用客户端配置
mieru apply config /path/to/client_config.json

# 启动 Mieru 客户端
mieru start

# 检查运行状态
mieru status

# 查看版本信息
mieru version

启动后,Mieru 会在 socks5Port 指定的端口(默认 1080)监听 SOCKS5 代理请求。将系统或浏览器的代理设置指向 127.0.0.1:1080 即可使用。

停止客户端

mieru stop

切换服务器

如果配置了多个 profile,可以通过修改 activeProfile 字段并重新应用配置来切换服务器:

# 修改配置文件中的 activeProfile 字段后重新应用
mieru apply config /path/to/client_config.json
mieru stop
mieru start

与第三方客户端配合使用

Mieru 客户端启动后在本地暴露一个标准的 SOCKS5 代理端口,可以被任何支持 SOCKS5 的工具使用,包括 Mihomo(Clash)、sing-box 等:

Mihomo 配置(将 Mieru 作为上游代理):

proxies:
- name: "mieru-local"
type: socks5
server: 127.0.0.1
port: 1080

这种方式可以让你在 Mihomo 的分流规则框架下使用 Mieru 节点,同时享受 Mihomo 丰富的规则功能。

关于混合使用

将 Mieru 客户端作为本地 SOCKS5 代理,然后在 Mihomo 或 sing-box 中将其作为上游节点,是在不支持原生 Mieru 协议的客户端上使用 Mieru 的推荐方式。这种方式在桌面端可行,但在移动端操作较为复杂。

客户端支持

由于 Mieru 是一个较小众的协议,主流代理软件中直接支持它的并不多:

平台客户端支持状态备注
Windows / macOS / LinuxMieru 原版客户端完整支持官方客户端,功能最完整
Windows / macOS / LinuxMihomo不支持(原生)可通过本地 SOCKS5 中转
Windows / macOS / Linuxsing-box不支持(原生)可通过本地 SOCKS5 中转
iOSShadowrocket不支持
iOSQuantumult X不支持
iOSStash / Surge不支持
AndroidNekoBox支持(部分版本)通过 sing-box 集成
AndroidHusi支持sing-box 内核,部分版本支持
AndroidExclave支持
关于 iOS 平台

Mieru 在 iOS 平台基本没有可用的客户端支持。如果你的主力设备是 iPhone,Mieru 不适合作为你的主力协议。建议在 iOS 上使用 VLESS + Reality、Hysteria 2 等支持更广泛的协议。

常见问题

Q:Mieru 和 Shadowsocks 相比有什么优势?

两者都不依赖 TLS,但设计思路有所不同:

  • Shadowsocks(AEAD)有固定长度的协议头部(salt + 加密内容),这个结构特征可以被针对性检测
  • Mieru 的数据包大小通过随机填充进行了随机化,没有固定长度的可识别结构
  • Mieru 的握手过程也经过了随机化处理,没有固定的握手特征
  • 但 Mieru 在实际抗检测能力上的表现并没有明显领先于 Shadowsocks 2022,两者都属于"一般"级别

在实际使用中,如果你的主要关切是抗检测能力,VLESS + Reality 或 Hysteria 2 的效果远优于两者。

Q:Mieru 支持 TCP 模式吗,什么时候用 TCP 而非 UDP?

Mieru 同时支持 UDP 和 TCP 传输模式,在 portBindings.protocol 中配置。建议在以下情况下使用 TCP 模式:

  • UDP 被明确封锁或 QoS 限速的网络环境
  • 需要通过 HTTP 代理或端口转发连接服务器(此类中间件通常只支持 TCP)

UDP 模式通常具有更低的延迟,推荐在 UDP 可用时优先使用。

Q:连接失败,没有任何错误提示怎么办?

Mieru 在密钥不匹配时会静默丢弃数据包,不返回错误。如果连接始终失败:

  1. 确认客户端和服务端的 user.nameuser.password 完全一致(区分大小写)
  2. 确认端口号和协议类型(UDP/TCP)一致
  3. 确认服务端防火墙已开放对应端口
  4. 在服务端运行 mita get log 查看是否有连接记录
  5. 确认服务端的 mita status 显示正在运行

Q:Mieru 可以作为透明代理(TUN 模式)使用吗?

Mieru 原版客户端只提供 SOCKS5 代理接口,不支持 TUN 模式。如果需要透明代理,可以将 Mieru 的 SOCKS5 接口接入支持 TUN 的代理工具(如通过 Mihomo 的 socks5 入站 + Mieru 作为上游出站的组合)。但这种组合在移动端配置较为繁琐。

Q:Mieru 的流量在流量分析下安全吗?

Mieru 的随机填充和无固定握手特征使其在被动流量特征识别上有一定优势,但社区对其长期抗检测能力的评估为"一般"。在强力的主动探测下,Mieru 不如 VLESS + Reality 安全。如果安全性是第一优先级,建议使用 VLESS + Reality 或 AnyTLS。

延伸阅读