Xray-core
Xray-core copied to clipboard
Published
20 hours ago •
XTLS
XTLS
tls: bad record MAC
完整性要求
- [X] 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
- [X] 我搜索了issues，没有发现已提出的类似问题。
版本
1.8.11
描述
client -> server1 -(vless+tcp+reality)-> server2 -(vless+tcp+reality)-> server3
server1 xray 1.8.11 (normal) outbound1(vless+tcp+reality[to server3])->streamSettings("dialerProxy": "outbound2",) outbound2(vless+tcp+reality[to server2])
server2 xray 1.8.11 (normal)
server3 xray 1.8.11 (error) app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > local error: tls: bad record MAC
重现方式
server1 - outbound
{
"tag": "out-server3",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "server3",
"port": 443,
"users": [
......
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
......
},
"sockopt": {
"dialerProxy": "out-server2",
"mark": 255
}
}
},
{
"tag": "out-server2",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "server2",
"port": 443,
"users": [
......
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
......
},
"sockopt": {
"mark": 255
}
}
},
===============================
server2 -
inbound: {
"tag": "in-reality",
"protocol": "vless",
"port": 443,
"settings": {
"clients": [
......
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
......
}
}
},
outbound : freedom
===============================
server3 - inbound
{
"tag": "in-reality",
"protocol": "vless",
"port": 443,
"settings": {
"clients": [
......
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
......
}
}
},
日志
server3 出現 error tls: bad record MAC
app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > local error: tls: bad record MAC
我也遇到了在使用REALITY dialerProxy时会出现的问题，不确定是否与此问题同源。 反向代理bridge (VLESS TCP) 通过dailerProxy由Reality代理时，外部访问内部网络会出现断连（bridge设备REALITY outbound断连，触发原因未知，触发随机，推测是连接数多，通常在连续使用一段时间后出现），断连后经过20分钟左右会自动恢复连接。 在之前版本（XTLS VISION）并没有这个问题，应该是在 1.8.0之后出现的问题。 确定1.8.6至1.8.11版本均有此问题。
client bridge (outbound VLESS TCP) --dialerProxy (through outbound REALITY)--> server (inbound REALITY) ----> server portal (inbound VLESS TCP)
环境为旁路由（bridge设备）透明代理 bridge 配置如下
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
...
}
]
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"allowInsecure": false,
"fingerprint": "chrome",
"publicKey": "...",
"serverName": "...",
"shortId": "",
"show": false,
"spiderX": "/a"
},
"sockopt": {
"mark": 255
}
}
},
{
"tag": "direct",
"protocol": "freedom",
"settings": {
"domainStrategy": "UseIPv4v6"
},
"streamSettings": {
"sockopt": {
"mark": 255
}
}
},
{
"tag": "bridge-home1-in",
"protocol": "vless",
"settings": {
"vnext": [
{
...
}
]
},
"streamSettings": {
"sockopt": {
"dialerProxy": "proxy"
}
}
}
],
"reverse": {
"bridges": [
{
"tag": "bridge-home1",
"domain": "home1.reverse.com"
}
]
},
"routing": {
"domainMatcher": "mph",
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"inboundTag": [
"bridge-home1"
],
"domain": [
"full:home1.reverse.com"
],
"outboundTag": "bridge-home1-in"
},
{
"type": "field",
"inboundTag": [
"bridge-home1"
],
"outboundTag": "direct"
}
]
}
portal 配置如下
"inbounds": [
{
"tag": "realityin",
"port": 443,
"protocol": "vless",
"settings": {
"clients": [
{
...
}
],
"decryption": "none"
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "...:443",
"xver": 0,
"serverNames": [
"..."
],
"privateKey": "...",
"shortIds": [
""
]
}
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
],
"domainsExcluded": [
"courier.push.apple.com"
]
}
},
{
"tag": "home1-in",
"listen": "MY_VPS_IP",
"port": 20002,
"protocol": "vless",
"settings": {
"clients": [
{
...
}
],
"decryption": "none"
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic"
],
"domainsExcluded": [
"courier.push.apple.com"
]
}
}
],
"reverse": {
"portals": [
{
"tag": "portal-home1",
"domain": "home1.reverse.com"
}
]
},
"routing": {
"domainMatcher": "mph",
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"inboundTag": [
"home1-in"
],
"outboundTag": "portal-home1"
}
{
"type": "field",
"inboundTag": [
"realityin"
],
"ip": [
"INTERNAL_SERVER_IP"
],
"outboundTag": "portal-home1"
}
]
}
出现断连时bridge日志出现如下报错 Xray_log.txt
同时在断连期间，bridge 设备ping VPS 的 IP 正常 portal VPS 端无此 bridge 连接日志，其他设备（不经过此bridge设备）连接VPS REALITY inbound 正常。
应该修好了 麻烦测试一下最新的构建 https://github.com/XTLS/Xray-core/actions/runs/9072508584 我大体测了一下 感觉 xtls 协议用在客户端的链式代理其实非常好用 因为一般的链式是额外双层加密解密 而 xtls 可以做到连接头双层加密 后面跨两层裸奔 同时两个服务器都是端口转发 非常高效 CC @RPRX @SQLimit 原问题是 100% 复现的 你说的问题如果可以还稳定复现麻烦重开一个 issue
已用 https://github.com/XTLS/Xray-core/actions/runs/9072508584 测试 未知在那引发问题 看似是由inbound 引发 未正式进行测试, 只更换了新xray, 就有一个v2rayng进入, 就引发了error
xtls error.log 最後讯息
11:00:54 [Info] [2390586618] proxy/vless/inbound: firstLen = 1186
11:00:54 [Info] [2390586618] proxy/vless/inbound: received request for tcp:voilatile-pa.googleapis.com:443
11:00:54 [Info] [2390586618] proxy: Xtls Unpadding new block, content 517 padding 803 command 0
11:00:54 [Info] [2390586618] proxy: XtlsFilterTls found tls client hello! 517
11:00:54 [Info] [2390586618] app/dispatcher: taking detour [out-AsIs-direct] for [tcp:voilatile-pa.googleapis.com:443]
11:00:54 [Info] [2390586618] transport/internet/tcp: dialing TCP to tcp:voilatile-pa.googleapis.com:443
11:00:54 [Info] [2390586618] proxy/freedom: connection opened to tcp:voilatile-pa.googleapis.com:443, local endpoint 192.168.7.252:39836, remote endpoint 142.250.66.106:443
11:00:54 [Info] [2390586618] proxy: CopyRawConn readv
11:00:54 [Info] [3095487748] proxy: XtlsFilterTls found tls 1.3! 4679 TLS_AES_128_GCM_SHA256
以下是 syslog 讯息
11:00:54 xray[5692]: panic: runtime error: index out of range [-1]
11:00:54 xray[5692]: goroutine 62 [running]:
11:00:54 xray[5692]: github.com/xtls/xray-core/proxy/vless/inbound.(*Handler).Process.func5()
11:00:54 xray[5692]: #011github.com/xtls/xray-core/proxy/vless/inbound/inbound.go:564 +0x89b
11:00:54 xray[5692]: github.com/xtls/xray-core/common/task.Run.func1(0xc003ed6ce0?)
11:00:54 xray[5692]: #011github.com/xtls/xray-core/common/task/task.go:28 +0x28
11:00:54 xray[5692]: created by github.com/xtls/xray-core/common/task.Run in goroutine 72
11:00:54 xray[5692]: #011github.com/xtls/xray-core/common/task/task.go:27 +0xdb
11:00:54 systemd[1]: xray.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
11:00:54 systemd[1]: xray.service: Failed with result 'exit-code'.
11:00:54 systemd[1]: xray.service: Scheduled restart job, restart counter is at 14.
11:00:54 systemd[1]: Stopped Xray Service.
11:00:54 systemd[1]: xray.service: Start request repeated too quickly.
11:00:54 systemd[1]: xray.service: Failed with result 'exit-code'.
11:00:54 systemd[1]: Failed to start Xray Service.
我大体测了一下 感觉 xtls 协议用在客户端的链式代理其实非常好用 因为一般的链式是额外双层加密解密 而 xtls 可以做到连接头双层加密 后面跨两层裸奔 同时两个服务器都是端口转发 非常高效
对性能来说是这样，对“不想让观察者关联两个或多个连接”来说不合适，所以还是不适合 tor，~~虽然它就多加密几层还是能被关联~~
对于“不想让观察者关联两个或多个连接”的起夜级需求，我想了下还是只能空跑流量抹平时序特征，like https://github.com/v2ray/v2ray-core/issues/2526#issuecomment-783931231 ，~~比 hysteria 的 brutal 更激进~~，不过这样的强特征又不适合过墙了，有点难取舍，~~好在我没有搞回国流量 ghs 的需求~~
@kingwilliam 麻烦再测一下 https://github.com/XTLS/Xray-core/actions/runs/9088697505
@kingwilliam 麻烦再测一下 https://github.com/XTLS/Xray-core/actions/runs/9088697505
- 已测试 dialerProxy 运作正常
- 早前测试的inbound问题也没再出现.
@kingwilliam 麻烦再测一下 https://github.com/XTLS/Xray-core/actions/runs/9088697505
长时间测试後(大约3小时) 先讲测试结果 还是有问题 问题同样出在 dialerProxy tls: bad record MAC
但跟之前不同 今次只是一些情况出现 如一般网页 看网页是没问题 但察看最後那个xray出口error.log 就会有tls: bad record MAC纪录 但如 linux apt http proxy 就一定会有问题
apt update
Hit:1 http://mirrors.ustc.edu.cn/debian bookworm InRelease
Hit:2 http://deb.debian.org/debian bookworm InRelease
Hit:3 http://haproxy.debian.net bookworm-backports-2.8 InRelease
Hit:4 http://archive.raspberrypi.com/debian bookworm InRelease
Hit:5 http://deb.debian.org/debian-security bookworm-security InRelease
Get:6 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
Err:6 http://deb.debian.org/debian bookworm-updates InRelease
Splitting up /var/lib/apt/lists/partial/deb.debian.org_debian_dists_bookworm-updates_InRelease into data and signature failed
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
N: Skipping acquire of configured file 'main/binary-armhf/Packages' as repository 'http://haproxy.debian.net bookworm-backports-2.8 InRelease' doesn't support architecture 'armhf'
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.debian.org/debian bookworm-updates InRelease: Splitting up /var/lib/apt/lists/partial/deb.debian.org_debian_dists_bookworm-updates_InRelease into data and signature failed
W: Failed to fetch http://deb.debian.org/debian/dists/bookworm-updates/InRelease Splitting up /var/lib/apt/lists/partial/deb.debian.org_debian_dists_bookworm-updates_InRelease into data and signature failed
W: Some index files failed to download. They have been ignored, or old ones used instead.
access.log
20:30:28 192.168.1.1:47954 accepted http://archive.raspberrypi.com/debian/dists/bookworm/InRelease [in-http -> out-xtls-tcp]
20:30:28 192.168.1.1:47938 accepted http://deb.debian.org/debian/dists/bookworm/InRelease [in-http -> out-xtls-tcp]
20:30:28 192.168.1.1:47966 accepted http://haproxy.debian.net/dists/bookworm-backports-2.8/InRelease [in-http -> out-xtls-tcp]
20:31:28 192.168.1.1:49146 accepted http://archive.raspberrypi.com/debian/dists/bookworm/InRelease [in-http -> out-xtls-tcp]
20:31:28 192.168.1.1:49168 accepted http://deb.debian.org/debian/dists/bookworm/InRelease [in-http -> out-xtls-tcp]
20:31:28 192.168.1.1:49144 accepted http://haproxy.debian.net/dists/bookworm-backports-2.8/InRelease [in-http -> out-xtls-tcp]
20:31:29 192.168.1.1:46242 accepted http://deb.debian.org/debian-security/dists/bookworm-security/InRelease [in-http -> out-xtls-tcp]
20:31:30 192.168.1.1:46254 accepted http://deb.debian.org/debian/dists/bookworm-updates/InRelease [in-http -> out-xtls-tcp]
error.log
20:30:28 [Info] [567602213] proxy/http: request to Method [GET] Host [haproxy.debian.net] with URL [http://haproxy.debian.net/dists/bookworm-backports-2.8/InRelease]
20:30:28 [Info] [2272979348] proxy/http: request to Method [GET] Host [archive.raspberrypi.com] with URL [http://archive.raspberrypi.com/debian/dists/bookworm/InRelease]
20:30:28 [Info] [2185294411] proxy/http: request to Method [GET] Host [deb.debian.org] with URL [http://deb.debian.org/debian/dists/bookworm/InRelease]
20:30:28 [Info] [2272979348] app/dispatcher: taking detour [out-xtls-tcp] for [tcp:archive.raspberrypi.com:80]
20:30:28 [Info] [2185294411] app/dispatcher: taking detour [out-xtls-tcp] for [tcp:deb.debian.org:80]
20:30:28 [Info] [2185294411] transport/internet/tcp: dialing TCP to tcp:www.xxx.yyy:777
20:30:28 [Info] [2272979348] transport/internet/tcp: dialing TCP to tcp:www.xxx.yyy:777
20:30:28 [Info] [2185294411] transport/internet: redirecting request tcp:www.xxx.yyy:777 to middle-xtls
20:30:28 [Info] [2272979348] transport/internet: redirecting request tcp:www.xxx.yyy:777 to middle-xtls
20:30:28 [Info] [2272979348] transport/internet/tcp: dialing TCP to tcp:aa.bb.cc:888
20:30:28 [Info] [567602213] app/dispatcher: taking detour [out-xtls-tcp] for [tcp:haproxy.debian.net:80]
20:30:28 [Info] [567602213] transport/internet/tcp: dialing TCP to tcp:www.xxx.yyy:777
20:30:28 [Info] [567602213] transport/internet: redirecting request tcp:www.xxx.yyy:777 to middle.xtls
20:30:28 [Info] [2185294411] transport/internet/tcp: dialing TCP to tcp:aa.bb.cc:888
20:30:28 [Info] [567602213] transport/internet/tcp: dialing TCP to tcp:aa.bb.cc:888
2024/05/15 20:40:29 [Info] [2272979348] proxy/vless/outbound: tunneling request to tcp:www.xxx.yyy:777 via aa.bb.cc:888
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls found tls client hello! 506
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsPadding 506 660 0
2024/05/15 20:40:29 [Info] [2185294411] proxy/vless/outbound: tunneling request to tcp:www.xxx.yyy:777 via aa.bb.cc:888
2024/05/15 20:40:29 [Info] [2185294411] proxy: XtlsFilterTls found tls client hello! 538
2024/05/15 20:40:29 [Info] [2185294411] proxy: XtlsPadding 538 436 0
2024/05/15 20:40:29 [Info] [567602213] proxy/vless/outbound: tunneling request to tcp:www.xxx.yyy:777 via aa.bb.cc:888
2024/05/15 20:40:29 [Info] [567602213] proxy: XtlsFilterTls found tls client hello! 602
2024/05/15 20:40:29 [Info] [567602213] proxy: XtlsPadding 602 484 0
2024/05/15 20:40:29 [Info] [2272979348] proxy: Xtls Unpadding new block, content 1448 padding 50 command 0
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls found tls 1.3! 1163 TLS_CHACHA20_POLY1305_SHA256
2024/05/15 20:40:29 [Info] [2272979348] proxy: Xtls Unpadding new block, content 1886 padding 108 command 0
2024/05/15 20:40:29 [Info] [2272979348] proxy/vless/outbound: tunneling request to tcp:archive.raspberrypi.com:80 via www.xxx.yyy:777
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsPadding 64 1227 0
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsFilterTls stop filtering232
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsPadding 47 36 1
2024/05/15 20:40:29 [Info] [2272979348] proxy: XtlsPadding 375 804 2
xtls 出口
error.log
20:30:31 [Info] [1525508074] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > local error: tls: bad record MAC
20:31:29 [Info] [2403976906] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > local error: tls: bad record MAC
20:31:29 [Info] [108597358] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > local error: tls: bad record MAC
20:31:30 [Info] [2940157922] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > local error: tls: bad record MAC
20:30:29 [Info] [1525508074] proxy/vless/inbound: firstLen = 353
20:30:29 [Info] [1525508074] proxy/vless/inbound: received request for tcp:archive.raspberrypi.com:80
20:30:29 [Info] [1525508074] app/dispatcher: taking detour [out-AsIs-direct] for [tcp:archive.raspberrypi.com:80]
20:30:29 [Info] [1525508074] transport/internet/tcp: dialing TCP to tcp:archive.raspberrypi.com:80
20:30:29 [Info] [1525508074] proxy: Xtls Unpadding new block, content 47 padding 36 command 1
20:30:30 [Info] [1525508074] proxy/freedom: connection opened to tcp:archive.raspberrypi.com:80, local endpoint 192.168.0.252:48858, remote endpoint 176.126.240.86:80
20:30:30 [Info] [1525508074] proxy: CopyRawConn readv
20:30:31 [Info] [1525508074] proxy: XtlsPadding 129 17 0
20:30:31 [Info] [1525508074] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > local error: tls: bad record MAC
20:31:29 [Info] [2403976906] proxy/vless/inbound: firstLen = 386
20:31:29 [Info] [2403976906] proxy/vless/inbound: received request for tcp:deb.debian.org:80
20:31:29 [Info] [2403976906] app/dispatcher: taking detour [out-AsIs-direct] for [tcp:deb.debian.org:80]
20:31:29 [Info] [2403976906] transport/internet/tcp: dialing TCP to tcp:deb.debian.org:80
20:31:29 [Info] [2403976906] proxy: Xtls Unpadding new block, content 47 padding 87 command 1
20:31:29 [Info] [2403976906] proxy/freedom: connection opened to tcp:deb.debian.org:80, local endpoint 192.168.0.252:41556, remote endpoint 151.101.78.132:80
20:31:29 [Info] [2403976906] proxy: CopyRawConn readv
20:31:29 [Info] [2403976906] proxy: XtlsPadding 278 71 0
20:31:29 [Info] [2403976906] app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer request payload > local error: tls: bad record MAC
我也遇到了在使用REALITY dialerProxy时会出现的问题，不确定是否与此问题同源。 反向代理bridge (VLESS TCP) 通过dailerProxy由Reality代理时，外部访问内部网络会出现断连（bridge设备REALITY outbound断连，触发原因未知，触发随机，推测是连接数多，通常在连续使用一段时间后出现），断连后经过20分钟左右会自动恢复连接。 在之前版本（XTLS VISION）并没有这个问题，应该是在 1.8.0之后出现的问题。 确定1.8.6至1.8.11版本均有此问题。
client bridge (outbound VLESS TCP) --dialerProxy (through outbound REALITY)--> server (inbound REALITY) ----> server portal (inbound VLESS TCP)环境为旁路由（bridge设备）透明代理 bridge 配置如下
"outbounds": [ { "tag": "proxy", "protocol": "vless", "settings": { "vnext": [ { ... } ] }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "allowInsecure": false, "fingerprint": "chrome", "publicKey": "...", "serverName": "...", "shortId": "", "show": false, "spiderX": "/a" }, "sockopt": { "mark": 255 } } }, { "tag": "direct", "protocol": "freedom", "settings": { "domainStrategy": "UseIPv4v6" }, "streamSettings": { "sockopt": { "mark": 255 } } }, { "tag": "bridge-home1-in", "protocol": "vless", "settings": { "vnext": [ { ... } ] }, "streamSettings": { "sockopt": { "dialerProxy": "proxy" } } } ], "reverse": { "bridges": [ { "tag": "bridge-home1", "domain": "home1.reverse.com" } ] }, "routing": { "domainMatcher": "mph", "domainStrategy": "AsIs", "rules": [ { "type": "field", "inboundTag": [ "bridge-home1" ], "domain": [ "full:home1.reverse.com" ], "outboundTag": "bridge-home1-in" }, { "type": "field", "inboundTag": [ "bridge-home1" ], "outboundTag": "direct" } ] }portal 配置如下
"inbounds": [ { "tag": "realityin", "port": 443, "protocol": "vless", "settings": { "clients": [ { ... } ], "decryption": "none" }, "streamSettings": { "network": "tcp", "security": "reality", "realitySettings": { "show": false, "dest": "...:443", "xver": 0, "serverNames": [ "..." ], "privateKey": "...", "shortIds": [ "" ] } }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls", "quic" ], "domainsExcluded": [ "courier.push.apple.com" ] } }, { "tag": "home1-in", "listen": "MY_VPS_IP", "port": 20002, "protocol": "vless", "settings": { "clients": [ { ... } ], "decryption": "none" }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls", "quic" ], "domainsExcluded": [ "courier.push.apple.com" ] } } ], "reverse": { "portals": [ { "tag": "portal-home1", "domain": "home1.reverse.com" } ] }, "routing": { "domainMatcher": "mph", "domainStrategy": "AsIs", "rules": [ { "type": "field", "inboundTag": [ "home1-in" ], "outboundTag": "portal-home1" } { "type": "field", "inboundTag": [ "realityin" ], "ip": [ "INTERNAL_SERVER_IP" ], "outboundTag": "portal-home1" } ] }出现断连时bridge日志出现如下报错 Xray_log.txt
同时在断连期间，bridge 设备ping VPS 的 IP 正常 portal VPS 端无此 bridge 连接日志，其他设备（不经过此bridge设备）连接VPS REALITY inbound 正常。
测试最新1.8.13版本已无此问题。
@kingwilliam 我 ubuntu 本地好久没更新 累积了300多MB 用 http 代理链 更新了半个小时 中间遇到过一次出错 重试就好了 我看了一下貌似不是代理的问题 而且原问题已经修复 所以先关了 如果有可以稳定复现的问题 欢迎再反馈
收到, 我会再留意情况, 谢谢
=====
原问题 client -> server1 -(vless+tcp+reality)-> server2 -(vless+tcp+reality)-> server3
补充 : client -(http/tproxy)-> server1 -(vless+tcp+reality)-> server2 -(vless+tcp+reality)-> server3
client : 有 android, ios, windows, ubuntu server1 : 有 Debian 12, ubuntu 22.04 server2 : ubuntu 22.04 server3 : ubuntu 22.04
=====
修改 client -(http/tproxy)-> server1 -(vless+tcp+reality)-> server2 -(vless+tls+grpc)-> server3
如修改 由: server2 -(vless+tcp+reality)-> server3 到: server2 -(vless+tls+grpc)-> server3
tls: bad record MAC 就不会再出现
=====
1.8.13 tls: bad record MAC 问题还存在, 但只会在一些情况出现, 但要详细测试才可给出 出现场景