Bug Confirmed #6319: Upstream Xray-core v26.6.1 SOCKS Inbound Handshake Panic
### Integrity requirements
- [x] I have read all the comments in the issue template and ensured that this issue meet the requirements.
- [x] I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
- [x] I provided the complete config and logs, rather than just providing the truncated parts based on my own judgment.
- [x] I searched issues and did not find any similar issues.
- [x] The problem can be successfully reproduced in the latest Release
### Description
I have successfully bypassed all Android-layer app wrapper variables by running the official native `Xray-linux-arm64-v8a` binary (v26.6.1) directly inside a native Termux environment using a basic loopback chaining configuration.
The core runs for roughly a minute under LAN load before suffering a fatal runtime panic. This completely rules out Android memory allocation (`userfaultfd`), or client library packaging.
### Fatal Stack Trace:
panic: Calling IP() on a DomainAddress.
### Agreement on TUN status: Isolating the Application Layer
I completely agree that the TUN module has not changed. This investigation isolates the bug entirely away from the Network Layer (TUN/VPN) and proves the regression is located squarely within the Application Layer protocol handlers.
By running the official native `Xray-linux-arm64-v8a` binary directly inside Termux, **the TUN interface was completely bypassed and never initialized.**
This setup relies purely on standard OS network sockets:
1. **Inbound (Application Layer):** A standard `socks` listening port on `0.0.0.0:1080` accepting raw socket connections from downstream LAN clients.
2. **Outbound (Application Layer):** A simple proxy chain transferring app-layer payloads straight to a local loopback port (`127.0.0.1:10808`).
Because no virtual network adapter (TUN) or routing rules are active in this native test environment, the fatal crash trace `proxy/socks.(*ServerSession).handshake5` confirms that the panic is occurring during a pure application-layer SOCKS5 string-parsing handshake.
### Conclusion:
The regression was introduced between v26.5.9 (which handles this configuration flawlessly) and v26.6.1. The SOCKS inbound server session parsing logic (`handshake5`) is incorrectly calling the `.IP()` abstraction method on native `DomainAddress` variables, forcing a fatal Go runtime panic. Please reopen and investigate this structural type-checking regression.
### Reproduction Method
- **Inbound:** SOCKS5 listening on `0.0.0.0` with UDP enabled (handling downstream LAN client traffic).
- **Outbound:** A simple SOCKS5 loopback proxy chain to `127.0.0.1:10808`.
- **Trigger:** Downstream LAN clients sending standard SOCKS5 requests targeting absolute domain addresses
### Client config
<details><pre><code>
{
"log": {
"loglevel": "warning"
},
"dns": {
"servers": [
"1.1.1.1",
"8.8.8.8"
]
},
"inbounds": [
{
"tag": "lan-socks-in",
"port": 1080,
"listen": "0.0.0.0",
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
},
{
"tag": "lan-http-in",
"port": 1081,
"listen": "0.0.0.0",
"protocol": "http",
"settings": {
"allowRedirect": true
}
}
],
"outbounds": [
{
"tag": "loopback-out",
"protocol": "socks",
"settings": {
"servers": [
{
"address": "127.0.0.1",
"port": 10808
}
]
},
"streamSettings": {
"sockopt": {
"domainStrategy": "UseIP"
}
}
}
]
}
</code></pre></details>
### Server config
N/A
### Client log
=== Environment ===
OS: Android (Linux arm64 binary via Termux)
Core Version: Xray-core v26.6.1
Inbound Protocol: SOCKS5 (with UDP enabled, listening on 0.0.0.0)
Outbound Protocol: SOCKS5 Loopback Chain (127.0.0.1:10808)
=== Crash Log Trace ===
2026/06/13 22:21:09.507960 from tcp:10.163.52.49:54410 accepted tcp:c.clarity.ms:443 [lan-socks-in >> loopback-out]
2026/06/13 22:21:09.549986 from tcp:10.163.52.49:54412 accepted tcp:whatismyipaddress.com:443 [lan-socks-in >> loopback-out]
2026/06/13 22:21:10.082646 from tcp:10.163.52.241:53250 accepted tcp:13.89.179.11:443 [lan-socks-in >> loopback-out]
2026/06/13 22:21:10.196168 from tcp:10.163.52.49:54414 accepted tcp:c.bing.com:443 [lan-socks-in >> loopback-out]
2026/06/13 22:21:11.820187 from tcp:10.163.52.241:53257 accepted udp:40.99.10.82:443 [lan-socks-in >> loopback-out]
panic: Calling IP() on a DomainAddress.
goroutine 853 [running]:
github.com/xtls/xray-core/common/net.domainAddress.IP(...)
github.com/xtls/xray-core/common/net/address.go:172
github.com/xtls/xray-core/proxy/socks.(*ServerSession).handshake5(0x7413ab5d20, 0x1?, {0x12d8c60, 0x7413c41200}, {0x12f6b28, 0x74131b0fa8})
github.com/xtls/xray-core/proxy/socks/protocol.go:212 +0x480
github.com/xtls/xray-core/proxy/socks.(*ServerSession).Handshake(0x7413ab5d20, {0x12d8c60, 0x7413c41200}, {0x12f6b28, 0x74131b0fa8})
github.com/xtls/xray-core/proxy/socks/protocol.go:245 +0x14c
github.com/xtls/xray-core/proxy/socks.(*Server).processTCP(0x74134b23c0, {0x12ed000, 0x7413c41170}, {0x7414e13500, 0x74131b0fa8}, {0x12efdc0, 0x74134a8610}, {0x7413c46070, 0x1, 0x1})
github.com/xtls/xray-core/proxy/socks/server.go:121 +0x3e0
github.com/xtls/xray-core/proxy/socks.(*Server).Process(0x74134b23c0, {0x12ed000, 0x7413c41170}, 0x2, {0x7414e13500, 0x74131b0fa8}, {0x12efdc0, 0x74134a8610})
github.com/xtls/xray-core/proxy/socks/server.go:90 +0x210
github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).callback(0x7413382460, {0x7414e13500, 0x74131b0fa8})
github.com/xtls/xray-core/app/proxyman/inbound/worker.go:123 +0xbd0
created by github.com/xtls/xray-core/app/proxyman/inbound.(*tcpWorker).Start.func1 in goroutine 348
github.com/xtls/xray-core/app/proxyman/inbound/worker.go:142 +0x78
### Server log
N/A
0 条评论