[GH-ISSUE #2613] Linux XRay regression after 4.8.11.4: 4.8.12+ no longer ships xray binary #1188

New issue

Open

opened 2026-10-13 20:36:03 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-13 20:36:03 +00:00

Owner

Originally created by @theonekeyg on GitHub (May 17, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2613

Hi maintainers. I’m trying to understand whether this is an expected backend/packaging change or a Linux regression. I can provide more logs if helpful.

Short version

XRay/VLESS works for me with AmneziaVPN 4.8.10.0 on Linux, but does not work with newer Linux releases such as 4.8.14.5 and 4.8.15.4.

The same self-hosted VLESS server/inbound works from another machine, and also works on this laptop after downgrading to 4.8.10.0.

Package difference I found

I inspected the Linux release installer payloads and found this boundary:

Version	Linux payload contains `client/bin/xray`?
`4.8.10.0`	yes, `client/bin/xray` + `xray.sha256`
`4.8.11.4`	yes, `client/bin/xray` + `xray.sha256`
`4.8.12.7`	no
`4.8.12.8`	no
`4.8.12.9`	no
`4.8.14.1`	no
`4.8.14.5`	no
`4.8.15.0`	no
`4.8.15.4`	no

This seems to match a source-level change:

4.8.11.4: client/protocols/xrayprotocol.cpp launches an external xray executable.
4.8.12.x+: XRay is started through IPC and handled by AmneziaVPN-service via amnezia_xray_start().
The likely transition is #1899 (feat: native split-tunneling for xray).

So maybe removing the standalone xray binary was intentional. The problem is that the replacement path does not appear to work on my Linux system.

Runtime symptom on broken versions

On 4.8.14.5 / 4.8.15.4:

UI says connected.
tun2 is created.
tun2socks runs and points at a local SOCKS listener owned by AmneziaVPN-service.
There is no separate xray process.
The local SOCKS listener accepts the connection.
curl through that SOCKS proxy sends the TLS ClientHello, then waits until timeout.
tcpdump on the uplink interface sees no packets to the VLESS server during that SOCKS test.

So this does not look like only DNS: even a direct SOCKS test without DNS does not complete.

Environment

Ubuntu 26.04 LTS
Kernel 7.0.0-15-generic
KDE, X11
Protocol: self-hosted XRay/VLESS
Working client version: 4.8.10.0
Broken client versions tested: 4.8.14.5, 4.8.15.4

Questions

Was the standalone Linux xray binary intentionally removed starting with 4.8.12.x?
Is the embedded AmneziaVPN-service XRay backend expected to fully replace it on Linux?
If yes, what logs or debug checks would help identify why the embedded backend accepts the local SOCKS stream but appears not to send traffic to the VLESS server?

Thanks.

Originally created by @theonekeyg on GitHub (May 17, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/2613 Hi maintainers. I’m trying to understand whether this is an expected backend/packaging change or a Linux regression. I can provide more logs if helpful. ### Short version XRay/VLESS works for me with AmneziaVPN `4.8.10.0` on Linux, but does not work with newer Linux releases such as `4.8.14.5` and `4.8.15.4`. The same self-hosted VLESS server/inbound works from another machine, and also works on this laptop after downgrading to `4.8.10.0`. ### Package difference I found I inspected the Linux release installer payloads and found this boundary: | Version | Linux payload contains `client/bin/xray`? | |---|---| | `4.8.10.0` | yes, `client/bin/xray` + `xray.sha256` | | `4.8.11.4` | yes, `client/bin/xray` + `xray.sha256` | | `4.8.12.7` | no | | `4.8.12.8` | no | | `4.8.12.9` | no | | `4.8.14.1` | no | | `4.8.14.5` | no | | `4.8.15.0` | no | | `4.8.15.4` | no | This seems to match a source-level change: - `4.8.11.4`: `client/protocols/xrayprotocol.cpp` launches an external `xray` executable. - `4.8.12.x+`: XRay is started through IPC and handled by `AmneziaVPN-service` via `amnezia_xray_start()`. - The likely transition is #1899 (`feat: native split-tunneling for xray`). So maybe removing the standalone `xray` binary was intentional. The problem is that the replacement path does not appear to work on my Linux system. ### Runtime symptom on broken versions On `4.8.14.5` / `4.8.15.4`: - UI says connected. - `tun2` is created. - `tun2socks` runs and points at a local SOCKS listener owned by `AmneziaVPN-service`. - There is no separate `xray` process. - The local SOCKS listener accepts the connection. - `curl` through that SOCKS proxy sends the TLS ClientHello, then waits until timeout. - `tcpdump` on the uplink interface sees no packets to the VLESS server during that SOCKS test. So this does not look like only DNS: even a direct SOCKS test without DNS does not complete. ### Environment - Ubuntu 26.04 LTS - Kernel `7.0.0-15-generic` - KDE, X11 - Protocol: self-hosted XRay/VLESS - Working client version: `4.8.10.0` - Broken client versions tested: `4.8.14.5`, `4.8.15.4` ### Questions 1. Was the standalone Linux `xray` binary intentionally removed starting with `4.8.12.x`? 2. Is the embedded `AmneziaVPN-service` XRay backend expected to fully replace it on Linux? 3. If yes, what logs or debug checks would help identify why the embedded backend accepts the local SOCKS stream but appears not to send traffic to the VLESS server? Thanks.

bsakaguchi commented

2026-10-13 20:36:04 +00:00

Author

Owner

@ygurov commented on GitHub (May 18, 2026):

Hi @theonekeyg

Answering the questions:
1). Yes, that removal was intentional. The reason we did that is the need of the additional capabilities on socket options. Specifically, binding xray-created sockets to specific interfaces to prevent routing loops in multi-endpoint configurations.
Now xray is getting linked as a library to the service application, and starts within the service itself. Tun2socks is still used for providing TUN functionality for xray.
2). Yes, xray embedded as a part of AmneziaVPN-service and provides a full solution in the same way as it was a standalone application
3). Service log contains xray logs. It could be useful for debug. You can also still specify a custom loglevel/log path as a part of xray configuration https://xtls.github.io/en/config/log.html#logobject

@ygurov commented on GitHub (May 18, 2026): Hi @theonekeyg Answering the questions: 1). Yes, that removal was intentional. The reason we did that is the need of the additional capabilities on socket options. Specifically, binding xray-created sockets to specific interfaces to prevent routing loops in multi-endpoint configurations. Now xray is getting linked as a library to the service application, and starts within the service itself. Tun2socks is still used for providing TUN functionality for xray. 2). Yes, xray embedded as a part of `AmneziaVPN-service` and provides a full solution in the same way as it was a standalone application 3). Service log contains xray logs. It could be useful for debug. You can also still specify a custom loglevel/log path as a part of xray configuration https://xtls.github.io/en/config/log.html#logobject

bsakaguchi referenced this issue

2026-10-13 21:20:17 +00:00

[PR #1188] [MERGED] chore/using the global network manager #2263