背景
在企业内网环境中部署服务时,经常会遇到这样的问题:
- 公司防火墙拦截了frp、rathole等常见内网穿透工具的协议特征
- SSH隧道被DPI(深度包检测)识别并阻断
- 开放的端口有限,仅允许80/443等常见端口出站
- 传统穿透方案需要额外开放端口,增加了暴露面
我们需要一种方案:既能穿透内网暴露服务,又能伪装成正常HTTPS流量绕过防火墙检测,同时还能作为梯子使用。
方案对比
| 方案 | 性能 | 抗检测 | 备注 |
|---|---|---|---|
| frp | 高 | 差 | 自定义协议特征明显,容易被DPI识别和阻断 |
| rathole | 高 | 差 | 基于Noise协议,性能优秀但协议指纹已进入黑名单 |
| SSH隧道 | 中 | 中 | 加密流量,但SSH握手特征明显,企业防火墙通常直接拦截 |
| Xray VLESS+REALITY | 高 | 强 | 流量与正常HTTPS访问完全一致,目前无已知检测手段 |
frp和rathole在性能上表现优秀,连接稳定、延迟低,但它们的协议特征已经被主流防火墙和DPI设备收录。在企业环境中,这些工具的连接往往在建立阶段就被拦截。
Xray的VLESS+REALITY+Vision组合完美解决了这个问题。REALITY协议不需要域名和证书,直接复用TLS握手,流量特征与访问正常HTTPS网站完全一致。配合反向代理功能,一个443端口同时承载多服务穿透和梯子。
架构说明
┌──────────────────┐ ┌──────────────────┐
│ 内网机器(A) │ │ 公网服务器(B) │
│ │ vless+reality │ │
│ ┌────────────┐ │ ◄════════════════► │ ┌────────────┐ │
│ │ xray-bridge│ │ port 443 │ │xray-portal │ │
│ └────┬───────┘ │ │ └────┬───────┘ │
│ │ │ │ │ │
│ ┌────┴───────┐ │ │ ┌────┴───────┐ │
│ │ 本地服务 │ │ │ │ 80/8081/ │ │
│ │ :80 │ │ │ │ 8082端口 │ │
│ │ :8001 │ │ │ │ (公网访问) │ │
│ │ :8002 │ │ │ └────────────┘ │
│ └────────────┘ │ │ │
└──────────────────┘ └──────────────────┘
流量走向
- 内网穿透:bridge用
.internal域名连接portal → portal识别为隧道注册 → 外部HTTP流量通过dokodemo-door进入 → portal转发给bridge → bridge转发给本地服务 - 梯子:普通客户端用任意域名连接443 → portal识别为普通流量 → freedom直连出站
两种流量共用同一个vless+reality入站,portal通过域名自动区分。
关键配置
公网服务器(portal端)
/usr/local/etc/xray/config.json:
|
|
内网机器(bridge端)
/usr/local/etc/xray/bridge-config.json:
|
|
Systemd 服务配置
bridge端
|
|
portal端
|
|
生成 Reality 密钥对
|
|
作为梯子使用
portal的443端口同时支持梯子功能。任何支持VLESS的客户端都可以连接使用。
节点链接(可直接导入v2rayN/Clash)
vless://替换UUID@替换公网IP:443?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=替换公钥&sid=替换shortId&spx=%2F&type=tcp#节点名称
Clash配置示例
|
|
注意事项
- 版本一致性:bridge和portal必须使用相同版本的Xray
- 不要重复开启Mux:反向代理底层已使用Mux.cool,不要在interconn outbound上再次开启mux
- 启动顺序:建议先启动bridge,再启动portal
- bridge端不需要inbound:reverse.bridges本身就是虚拟inbound,不需要额外配置dokodemo-door
- 域名路由规则顺序:
.internal的规则必须放在direct规则之前 - 穿透服务数量:每增加一个穿透服务,需要在两端各加一组bridge/portal + 对应的路由规则

说些什么吧!