VLESS on 猫猫鱼的小窝

Xray 新版 VLESS Reverse Proxy 单隧道承载多端口内网穿透

xxx@example.com (catcatyu) — Mon, 08 Jun 2026 14:20:46 +0800

Xray 新版 VLESS Reverse Proxy 单隧道承载多端口内网穿透

作者：catcatyu（xxx@example.com）

前言

之前写过一篇 Xray 反向代理多端口内网穿透配置，当时使用的是旧版顶层 reverse.portals / reverse.bridges 写法。那套方案能跑，但每暴露一个服务就要维护一组 portal/bridge tag 和一组 .internal 域名，服务数量多了以后配置会变得很长。

这次把同类场景更新为新版 VLESS reverse proxy 写法，并且没有继续采用“一项服务一条反向隧道”的保守迁移方式，而是改成 一条 VLESS reverse 隧道承载多个公网端口。

为了避免泄露真实环境，本文中的域名、IP、UUID、服务名、密码、密钥均已脱敏。直接复制配置前需要替换占位符。

迁移目标

原来的旧结构大概是这样：

1
2
3
4


公网 80   -> external-web     -> portal-web     -> bridge-web     -> 127.0.0.1:80
公网 8081 -> external-api     -> portal-api     -> bridge-api     -> 127.0.0.1:8001
公网 8082 -> external-admin   -> portal-admin   -> bridge-admin   -> 127.0.0.1:8002
公网 2222 -> external-ssh     -> portal-ssh     -> bridge-ssh     -> 127.0.0.1:22

每一行都要在公网端写 portal，在桥接端写 bridge，还要维护一条用于注册隧道的 .internal 域名路由。

更新后的结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


公网 80
公网 8081
公网 8082
公网 2222
公网 8083
公网 8084
公网 8085
    |
    v
同一个 reverse-out
    |
    v
同一个 reverse-in
    |
    +-- 目标端口 80   -> 127.0.0.1:80
    +-- 目标端口 8081 -> 127.0.0.1:8001
    +-- 目标端口 8082 -> 127.0.0.1:8002
    +-- 目标端口 2222 -> 127.0.0.1:22

公网端只负责把外部入口全部转进同一个 reverse-out，桥接端再根据请求保留下来的目标端口做二次分流。

为什么可以这么做

dokodemo-door 入站可以把公网端口上的连接包装成一个带目标地址和目标端口的请求。公网端把这些请求交给 VLESS reverse proxy 后，桥接端的 reverse-in 仍然可以基于 port 做路由匹配。

所以我们不再需要：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
  "reverse": {
    "portals": [
      {
        "tag": "portal-web",
        "domain": "tunnel-web.internal"
      }
    ]
  }
}

也不再需要桥接端的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
  "reverse": {
    "bridges": [
      {
        "tag": "bridge-web",
        "domain": "tunnel-web.internal"
      }
    ]
  }
}

新版写法把反向代理关系直接写在 VLESS client/outbound 里。

公网服务器侧：

1
2
3
4
5
6
7
8


{
  "id": "",
  "flow": "xtls-rprx-vision",
  "email": "bridge-single@example",
  "reverse": {
    "tag": "reverse-out"
  }
}

桥接端侧：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
  "protocol": "vless",
  "tag": "interconn",
  "settings": {
    "address": "proxy.example.com",
    "port": 443,
    "encryption": "none",
    "id": "",
    "flow": "xtls-rprx-vision",
    "reverse": {
      "tag": "reverse-in"
    }
  }
}

注意桥接端 outbound 必须使用 simplified outbound config style，也就是把 address、port、id、flow、reverse 直接写在 settings 下面。不要再写成旧的 vnext.users 结构，否则新版 reverse 会报错。

公网服务器配置

下面只展示核心配置。假设公网服务器原来已经有一个 VLESS + REALITY + Vision 入站，tag 为 interconn。

VLESS 入站

保留原有普通客户端，同时新增一个专门给桥接端使用的 reverse client：

 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


{
  "tag": "interconn",
  "listen": "0.0.0.0",
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [
      {
        "id": "",
        "flow": "xtls-rprx-vision"
      },
      {
        "id": "",
        "flow": "xtls-rprx-vision",
        "email": "bridge-single@example",
        "reverse": {
          "tag": "reverse-out"
        }
      }
    ],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "show": false,
      "dest": "www.example.com:443",
      "xver": 0,
      "serverNames": ["www.example.com"],
      "privateKey": "",
      "shortIds": [""]
    }
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "quic"]
  }
}

如果你的入口是普通 TLS，就保留原来的 tlsSettings。这里的重点是 clients 里新增了带 reverse.tag 的桥接客户端。

公网入口

公网端仍然用 dokodemo-door 暴露多个端口：

 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


[
  {
    "tag": "external-web",
    "listen": "0.0.0.0",
    "port": 80,
    "protocol": "dokodemo-door",
    "settings": {
      "address": "0.0.0.0",
      "port": 80,
      "network": "tcp"
    }
  },
  {
    "tag": "external-api",
    "listen": "0.0.0.0",
    "port": 8081,
    "protocol": "dokodemo-door",
    "settings": {
      "address": "0.0.0.0",
      "port": 8081,
      "network": "tcp"
    }
  },
  {
    "tag": "external-ssh",
    "listen": "0.0.0.0",
    "port": 2222,
    "protocol": "dokodemo-door",
    "settings": {
      "address": "0.0.0.0",
      "port": 2222,
      "network": "tcp"
    }
  }
]

settings.port 要保留和公网入口一致，因为桥接端后面会靠这个目标端口分流。

路由规则

旧配置通常会写成多条：

1
2
3
4


{
  "inboundTag": ["external-web"],
  "outboundTag": "portal-web"
}

新版单隧道可以合并为一条：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


{
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "external-web",
          "external-api",
          "external-admin",
          "external-ssh",
          "external-service-a",
          "external-service-b"
        ],
        "outboundTag": "reverse-out"
      },
      {
        "type": "field",
        "inboundTag": ["interconn"],
        "outboundTag": "direct"
      }
    ]
  }
}

reverse-out 不需要出现在 outbounds 数组里。它来自 VLESS client 的：

1
2
3


"reverse": {
  "tag": "reverse-out"
}

outbounds 里保留默认出口即可：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

桥接端配置

桥接端不再需要顶层 reverse.bridges。它只需要一个主动连接公网服务器的 VLESS outbound。

单 reverse outbound

 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


{
  "protocol": "vless",
  "tag": "interconn",
  "settings": {
    "address": "proxy.example.com",
    "port": 443,
    "encryption": "none",
    "id": "",
    "flow": "xtls-rprx-vision",
    "reverse": {
      "tag": "reverse-in"
    }
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "fingerprint": "chrome",
      "serverName": "www.example.com",
      "publicKey": "",
      "shortId": "",
      "spiderX": "/"
    }
  }
}

如果公网端是普通 TLS，桥接端就改成：

1
2
3
4
5
6
7
8


{
  "network": "tcp",
  "security": "tls",
  "tlsSettings": {
    "serverName": "proxy.example.com",
    "fingerprint": "chrome"
  }
}

本地服务出口

每个本地服务仍然用 freedom.redirect：

 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


[
  {
    "tag": "out-web",
    "protocol": "freedom",
    "settings": {
      "redirect": "127.0.0.1:80",
      "finalRules": [
        {
          "action": "allow",
          "network": "tcp",
          "ip": ["127.0.0.1"],
          "port": "80"
        }
      ]
    }
  },
  {
    "tag": "out-api",
    "protocol": "freedom",
    "settings": {
      "redirect": "127.0.0.1:8001",
      "finalRules": [
        {
          "action": "allow",
          "network": "tcp",
          "ip": ["127.0.0.1"],
          "port": "8001"
        }
      ]
    }
  },
  {
    "tag": "out-ssh",
    "protocol": "freedom",
    "settings": {
      "redirect": "127.0.0.1:22",
      "finalRules": [
        {
          "action": "allow",
          "network": "tcp",
          "ip": ["127.0.0.1"],
          "port": "22"
        }
      ]
    }
  }
]

finalRules 不是必须在所有旧配置里都出现，但新版配置里建议显式写上，只允许 reverse 流量访问需要暴露的本地端口。

按目标端口分流

这是单隧道方案的关键：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


{
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["reverse-in"],
        "port": "80",
        "outboundTag": "out-web"
      },
      {
        "type": "field",
        "inboundTag": ["reverse-in"],
        "port": "8081",
        "outboundTag": "out-api"
      },
      {
        "type": "field",
        "inboundTag": ["reverse-in"],
        "port": "2222",
        "outboundTag": "out-ssh"
      }
    ]
  }
}

这里匹配的是公网 dokodemo-door 保留下来的目标端口，不是桥接端本地服务的端口。例如公网 8081 最后可以转发到桥接端本机 127.0.0.1:8001。

验证流程

先在两端验证配置语法：

1
2


xray run -test -config /usr/local/etc/xray/config.json
xray run -test -config /usr/local/etc/xray/bridge-config.json

确认通过后再重启：

1
2


systemctl restart xray
systemctl restart xray-bridge

公网端看日志，应该能看到外部入口进入同一个 reverse-out：

1
2
3


external-web -> reverse-out
external-api -> reverse-out
external-ssh -> reverse-out

桥接端看配置摘要，应该没有顶层 reverse，并且 VLESS outbound 带有 reverse：

1
2


has_top_reverse false
reverse_outbounds [('interconn', 'vless', true)]

最后逐个测公网端口：

1
2
3


curl -I http://proxy.example.com/
curl -I http://proxy.example.com:8081/
ssh -p 2222 root@proxy.example.com

如果 SSH 能返回 banner，HTTP 服务能返回对应后端响应，说明公网入口、VLESS reverse 隧道和桥接端本地 redirect 都已经打通。

回滚

迁移前建议在两端都做备份：

1
2


cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.bak-before-single-vless-reverse
cp /usr/local/etc/xray/bridge-config.json /usr/local/etc/xray/bridge-config.json.bak-before-single-vless-reverse

如果切换后发现某个端口异常，可以直接恢复旧配置：

1
2


cp /usr/local/etc/xray/config.json.bak-before-single-vless-reverse /usr/local/etc/xray/config.json
systemctl restart xray

桥接端同理：

1
2


cp /usr/local/etc/xray/bridge-config.json.bak-before-single-vless-reverse /usr/local/etc/xray/bridge-config.json
systemctl restart xray-bridge

取舍

单隧道方案的优点：

配置明显更短；
不需要维护多组 .internal 域名；
只需要一个 bridge UUID；
多端口入口的流量都走同一条 reverse 通道，管理成本低；
从旧 reverse.portals/bridges 迁移到新版 VLESS reverse proxy 后，结构更贴近 Xray 当前推荐写法。

缺点也很明确：

所有服务共用一条 reverse 通道，故障影响面更大；
桥接端依赖目标端口路由，如果公网端 dokodemo-door 的目标端口写错，分流会错；
迁移时必须两端同时切换，不能只改公网端或只改桥接端。

如果是生产环境，保守做法是一项服务一条 reverse 隧道，出错时只影响单个服务。如果是在维护窗口内追求配置简洁和更少的连接管理开销，单隧道方案更合适。

本文2026-06-08首发于猫猫鱼的小窝，最后修改于2026-06-08

使用新版 VLESS Reverse Proxy 实现海外入口回国内出口

xxx@example.com (catcatyu) — Mon, 08 Jun 2026 14:00:17 +0800

使用新版 VLESS Reverse Proxy 实现海外入口回国内出口

作者：catcatyu（xxx@example.com）

前言

这篇记录一次比较典型的“回国出口”配置：公网服务器在海外，朋友仍然连接这台海外服务器的 VLESS/XTLS 入口，但访问国内网站时，流量会通过一条反向隧道转回国内机器，再从国内宽带出口访问目标网站。

整体目标是：

朋友继续使用公网服务器原来的 443 VLESS 入口；
国内机器不需要公网 IP，也不需要在路由器上做端口转发；
只把国内域名和国内 IP 转回国内出口，其他流量仍走海外服务器原来的出口；
使用 Xray 新版 VLESS reverse proxy 写法，不再使用旧的 reverse.portals / reverse.bridges。

为了避免泄露真实环境，本文中的域名、UUID、证书路径、用户标识都已经脱敏。直接复制前需要把占位符替换成自己的值。

架构

朋友客户端
    |
    | VLESS + TLS/REALITY + Vision
    v
海外公网服务器
    |
    | 命中 geosite:cn / geoip:cn
    | 转入 VLESS reverse proxy
    v
国内出口机器
    |
    | freedom 直连
    v
国内网站

反向连接由国内出口机器主动发起到海外服务器。海外服务器只需要保留原来的公网 443 入站，国内机器不暴露任何公网端口。

新旧写法区别

旧写法通常会在配置顶层写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
  "reverse": {
    "portals": [
      {
        "tag": "portal",
        "domain": "tunnel.internal"
      }
    ]
  }
}

新版 VLESS reverse proxy 不再依赖顶层 reverse.portals / reverse.bridges。它把 reverse 写进 VLESS client 或 VLESS outbound：

公网服务器侧：

1
2
3
4
5
6
7
8


{
  "id": "",
  "flow": "xtls-rprx-vision",
  "email": "cn-bridge@example",
  "reverse": {
    "tag": "cn-reverse-out"
  }
}

国内出口机器侧：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{
  "protocol": "vless",
  "settings": {
    "address": "proxy.example.com",
    "port": 443,
    "encryption": "none",
    "id": "",
    "flow": "xtls-rprx-vision",
    "reverse": {
      "tag": "cn-reverse-in"
    }
  }
}

公网服务器上的 cn-reverse-out 会表现为一个可路由的 outbound；国内出口机器上的 cn-reverse-in 会表现为一个可匹配的 inbound。

公网服务器配置

下面只展示关键片段。假设公网服务器原来已经有一个 VLESS + TLS/REALITY + Vision 入站，tag 为 vless-in。

入站新增两个用户

一个用户给国内机器建立反向隧道，一个用户给朋友使用。不要让朋友和自己共用同一个 UUID，否则服务端无法按用户分流。

 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


{
  "tag": "vless-in",
  "listen": "::",
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [
      {
        "id": "",
        "flow": "xtls-rprx-vision",
        "email": "self@example"
      },
      {
        "id": "",
        "flow": "xtls-rprx-vision",
        "email": "cn-bridge@example",
        "reverse": {
          "tag": "cn-reverse-out"
        }
      },
      {
        "id": "",
        "flow": "xtls-rprx-vision",
        "email": "cnfriend@example"
      }
    ],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "tcp",
    "security": "tls"
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "quic"],
    "routeOnly": true
  }
}

如果你的入口是 REALITY，就保留原来的 realitySettings；如果是普通 TLS 证书，就保留原来的 tlsSettings。这里的核心不是 TLS 还是 REALITY，而是新增的 reverse.tag 和朋友独立用户。

路由规则

只把朋友访问国内域名和国内 IP 的流量转进反向隧道：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "user": ["cnfriend@example"],
        "domain": ["geosite:cn"],
        "outboundTag": "cn-reverse-out"
      },
      {
        "type": "field",
        "user": ["cnfriend@example"],
        "ip": ["geoip:cn"],
        "outboundTag": "cn-reverse-out"
      }
    ]
  }
}

如果原配置里有 geoip:cn 或 geosite:cn 走 block 的规则，上面两条规则要放在 block 规则之前，否则国内流量会先被拦截。

outbounds 里仍然要保留一个默认出口，比如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

这样没有命中回国规则的流量不会误入反向隧道。

国内出口机器配置

国内机器负责主动连接海外服务器，并把反向进来的流量从本地网络发出去。

 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
50
51
52
53
54
55
56


{
  "log": {
    "loglevel": "warning"
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["cn-reverse-in"],
        "outboundTag": "cn-home-direct"
      }
    ]
  },
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "freedom",
      "tag": "cn-home-direct",
      "settings": {
        "finalRules": [
          {
            "action": "allow",
            "network": "tcp,udp",
            "ip": ["!geoip:private"]
          }
        ]
      }
    },
    {
      "protocol": "vless",
      "tag": "cn-reverse-bridge",
      "settings": {
        "address": "proxy.example.com",
        "port": 443,
        "encryption": "none",
        "id": "",
        "flow": "xtls-rprx-vision",
        "reverse": {
          "tag": "cn-reverse-in"
        }
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "proxy.example.com",
          "fingerprint": "chrome"
        }
      }
    }
  ]
}

这里的 finalRules 只允许访问非私网地址，避免朋友通过这条反向隧道访问国内出口机器所在局域网的私有网段。如果你就是要访问内网 NAS、路由器后台等资源，再按需放开具体 IP 和端口，不建议直接放开整个私网。

如果海外入口是 REALITY，国内机器的 streamSettings 改成类似下面这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
  "network": "tcp",
  "security": "reality",
  "realitySettings": {
    "serverName": "www.example.com",
    "publicKey": "",
    "shortId": "",
    "fingerprint": "chrome",
    "spiderX": "/"
  }
}

systemd 用户服务

如果国内机器没有 root 权限，也可以用用户级 systemd 跑 Xray。示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


[Unit]
Description=Xray CN reverse exit
After=network-online.target

[Service]
Type=simple
Environment=XRAY_LOCATION_ASSET=%h/.local/share/xray
ExecStart=%h/.local/xray/xray run -config %h/.config/xray-cn-exit/config.json
Restart=on-failure
RestartSec=5
NoNewPrivileges=true

[Install]
WantedBy=default.target

启动：

1
2
3


systemctl --user daemon-reload
systemctl --user enable --now xray-cn-exit.service
systemctl --user status xray-cn-exit.service --no-pager

如果要让用户退出登录后仍然保持运行，需要确认系统是否开启了 linger：

1

loginctl enable-linger "$USER"

这一步通常需要管理员权限。

朋友客户端配置

普通 TLS 入口的链接大概是：

1

vless://@proxy.example.com:443?encryption=none&security=tls&sni=proxy.example.com&fp=chrome&type=tcp&flow=xtls-rprx-vision#CN-Return

REALITY 入口的链接大概是：

1

vless://@proxy.example.com:443?encryption=none&security=reality&sni=www.example.com&fp=chrome&pbk=&sid=&type=tcp&flow=xtls-rprx-vision#CN-Return

关键是朋友使用独立的。服务端通过这个 UUID 对应的 email 识别出朋友，然后只把国内目标转进 cn-reverse-out。

验证

先分别测试配置语法：

1
2


xray run -test -config /usr/local/etc/xray/config.json
xray run -test -config ~/.config/xray-cn-exit/config.json

然后重启服务：

1
2


systemctl restart xray
systemctl --user restart xray-cn-exit.service

可以临时在本地起一个朋友客户端 SOCKS 入站测试：

1
2


curl -x socks5h://127.0.0.1:18088 -I https://www.baidu.com/
curl -x socks5h://127.0.0.1:18088 https://api.ipify.org

期望结果：

www.baidu.com 正常返回；
国内出口机器日志里能看到类似 cn-reverse-in -> cn-home-direct；
非国内目标仍显示海外服务器 IP，说明没有把所有流量都转回国内机器。

注意事项

朋友必须使用独立 UUID，不要复用自己的 UUID。
服务器上如果已有 geoip:cn / geosite:cn 拦截规则，回国规则要放在拦截规则之前。
不建议在公网服务器上额外开放无认证 SOCKS/HTTP 代理端口，朋友直接复用 VLESS 入口即可。
国内出口机器关机、断网或 Xray 服务停止后，朋友的国内分流会不可用。
国内出口侧建议默认禁止访问私网地址，只按需放开具体内网资源。

这套方案的核心是“公网服务器负责入口和分流，国内机器负责主动建立反向隧道和最终出口”。新版 VLESS reverse proxy 把反向代理关系收敛到 VLESS client/outbound 本身，配置比旧的 reverse.portals / reverse.bridges 更直观，也更适合和现有 XTLS/Vision 入口合并使用。

本文2026-06-08首发于猫猫鱼的小窝，最后修改于2026-06-08

Xray反向代理——多端口内网穿透绕过企业级防火墙兼容梯子配置方法

xxx@example.com (catcatyu) — Tue, 05 May 2026 20:00:00 +0800

Xray反向代理——多端口内网穿透绕过企业级防火墙兼容梯子配置方法

作者：catcatyu（xxx@example.com）

背景

在企业内网环境中部署服务时，经常会遇到这样的问题：

公司防火墙拦截了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：

  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
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112


{
  "log": {
    "loglevel": "warning"
  },
  "reverse": {
    "portals": [
      { "tag": "portal-ctfd",        "domain": "tunnel-ctfd.internal" },
      { "tag": "portal-param",       "domain": "tunnel-param.internal" },
      { "tag": "portal-unserialize", "domain": "tunnel-unserialize.internal" }
    ]
  },
  "inbounds": [
    {
      "tag": "interconn",
      "listen": "::",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          { "id": "替换为你的UUID", "flow": "xtls-rprx-vision" }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "www.microsoft.com:443",
          "xver": 0,
          "serverNames": ["www.microsoft.com"],
          "privateKey": "替换为xray x25519生成的私钥",
          "shortIds": ["替换为openssl rand -hex 8生成的值"]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"]
      }
    },
    {
      "tag": "external-ctfd",
      "listen": "::",
      "port": 80,
      "protocol": "dokodemo-door",
      "settings": { "address": "0.0.0.0", "port": 80, "network": "tcp" }
    },
    {
      "tag": "external-param",
      "listen": "::",
      "port": 8081,
      "protocol": "dokodemo-door",
      "settings": { "address": "0.0.0.0", "port": 8081, "network": "tcp" }
    },
    {
      "tag": "external-unserialize",
      "listen": "::",
      "port": 8082,
      "protocol": "dokodemo-door",
      "settings": { "address": "0.0.0.0", "port": 8082, "network": "tcp" }
    }
  ],
  "outbounds": [
    { "tag": "direct", "protocol": "freedom" },
    { "tag": "block", "protocol": "blackhole" }
  ],
  "routing": {
    "rules": [
      {
        "comment": "公网 HTTP 流量 → 对应 portal",
        "type": "field",
        "inboundTag": ["external-ctfd"],
        "outboundTag": "portal-ctfd"
      },
      {
        "type": "field",
        "inboundTag": ["external-param"],
        "outboundTag": "portal-param"
      },
      {
        "type": "field",
        "inboundTag": ["external-unserialize"],
        "outboundTag": "portal-unserialize"
      },
      {
        "comment": "bridge 来的隧道注册请求 → 对应 portal",
        "type": "field",
        "inboundTag": ["interconn"],
        "domain": ["full:tunnel-ctfd.internal"],
        "outboundTag": "portal-ctfd"
      },
      {
        "type": "field",
        "inboundTag": ["interconn"],
        "domain": ["full:tunnel-param.internal"],
        "outboundTag": "portal-param"
      },
      {
        "type": "field",
        "inboundTag": ["interconn"],
        "domain": ["full:tunnel-unserialize.internal"],
        "outboundTag": "portal-unserialize"
      },
      {
        "comment": "梯子流量（非 .internal 流量）",
        "type": "field",
        "inboundTag": ["interconn"],
        "outboundTag": "direct"
      }
    ]
  }
}

内网机器（bridge端）

/usr/local/etc/xray/bridge-config.json：

 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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88


{
  "log": {
    "loglevel": "warning"
  },
  "reverse": {
    "bridges": [
      { "tag": "bridge-ctfd",        "domain": "tunnel-ctfd.internal" },
      { "tag": "bridge-param",       "domain": "tunnel-param.internal" },
      { "tag": "bridge-unserialize", "domain": "tunnel-unserialize.internal" }
    ]
  },
  "outbounds": [
    {
      "tag": "interconn",
      "protocol": "vless",
      "settings": {
        "vnext": [{
          "address": "替换为公网服务器IP",
          "port": 443,
          "users": [{
            "id": "替换为你的UUID",
            "flow": "xtls-rprx-vision",
            "encryption": "none"
          }]
        }]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "fingerprint": "chrome",
          "serverName": "www.microsoft.com",
          "publicKey": "替换为xray x25519生成的公钥",
          "shortId": "替换为openssl rand -hex 8生成的值",
          "spiderX": "/"
        }
      }
    },
    {
      "tag": "out-ctfd",
      "protocol": "freedom",
      "settings": { "redirect": "127.0.0.1:80" }
    },
    {
      "tag": "out-param",
      "protocol": "freedom",
      "settings": { "redirect": "127.0.0.1:8001" }
    },
    {
      "tag": "out-unserialize",
      "protocol": "freedom",
      "settings": { "redirect": "127.0.0.1:8002" }
    }
  ],
  "routing": {
    "rules": [
      {
        "comment": "bridge 注册握手 → 连接 portal",
        "inboundTag": ["bridge-ctfd"],
        "domain": ["full:tunnel-ctfd.internal"],
        "outboundTag": "interconn"
      },
      {
        "inboundTag": ["bridge-param"],
        "domain": ["full:tunnel-param.internal"],
        "outboundTag": "interconn"
      },
      {
        "inboundTag": ["bridge-unserialize"],
        "domain": ["full:tunnel-unserialize.internal"],
        "outboundTag": "interconn"
      },
      {
        "comment": "portal 转发来的实际流量 → 本地服务",
        "inboundTag": ["bridge-ctfd"],
        "outboundTag": "out-ctfd"
      },
      {
        "inboundTag": ["bridge-param"],
        "outboundTag": "out-param"
      },
      {
        "inboundTag": ["bridge-unserialize"],
        "outboundTag": "out-unserialize"
      }
    ]
  }
}

Systemd 服务配置

bridge端

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# /etc/systemd/system/xray-bridge.service
[Unit]
Description=Xray Bridge (reverse proxy client)
After=network.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/xray run -config /usr/local/etc/xray/bridge-config.json
Restart=always
RestartSec=5
LimitNOFILE=1048576
User=root

[Install]
WantedBy=multi-user.target

portal端

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# /etc/systemd/system/xray.service
[Unit]
Description=Xray Portal (reverse proxy server)
After=network.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/xray run -config /usr/local/etc/xray/config.json
Restart=always
RestartSec=5
LimitNOFILE=1048576
User=root

[Install]
WantedBy=multi-user.target

生成 Reality 密钥对

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 安装 xray
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

# 生成密钥对（portal端用私钥，bridge端用公钥）
xray x25519

# 生成 shortId（两端保持一致）
openssl rand -hex 8

# 生成 UUID（两端保持一致）
xray uuid

作为梯子使用

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配置示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


proxies:
  - name: "xray-reality"
    type: vless
    server: 替换公网IP
    port: 443
    uuid: 替换UUID
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    reality-opts:
      public-key: 替换公钥
      short-id: 替换shortId
    client-fingerprint: chrome

注意事项

版本一致性：bridge和portal必须使用相同版本的Xray
不要重复开启Mux：反向代理底层已使用Mux.cool，不要在interconn outbound上再次开启mux
启动顺序：建议先启动bridge，再启动portal
bridge端不需要inbound：reverse.bridges本身就是虚拟inbound，不需要额外配置dokodemo-door
域名路由规则顺序：.internal的规则必须放在direct规则之前
穿透服务数量：每增加一个穿透服务，需要在两端各加一组bridge/portal + 对应的路由规则

参考文档

本文2026-05-05首发于猫猫鱼的小窝，最后修改于2026-05-05