I rewrote the mobile Xray client core in Rust after hitting iOS’s 50 MiB Network Extension limit

https://preview.redd.it/eyayrw6d40mh1.png?width=760&format=png&auto=webp&s=c6f1bf4f308ea97336748e1c948176975730c31d

Hi everyone. I want to share an open-source project I have been working on: xray-rust.

The project started because I repeatedly encountered memory problems while embedding xray-core in an iOS VPN application.

iOS runs packet tunnels inside a Network Extension process with a memory limit of roughly 50 MiB. Once the process crosses that limit, iOS terminates the tunnel without giving the application much opportunity to recover.

This is especially noticeable with connection bursts, routing and geodata, and transports such as XHTTP over HTTP/2. Similar behavior has been reported in Xray-core issues:

• High Xray client memory consumption with XHTTP/HTTP2
• iOS high memory usage/memory leak
• Memory growth in iOS applications using libXray

In the HTTP/2 case, pending upload streams can retain large buffers. A relatively small connection burst may therefore consume enough memory to reach the Network Extension limit. Other reports describe memory gradually growing from around 12 MiB to 50 MiB over several hours.

I do not think this means that every Go application necessarily leaks memory. The practical problem is that the current xray-core/Go stack makes it difficult to maintain a predictable memory ceiling inside an iOS Network Extension.

Instead of continuing to work around the limit, I implemented the mobile client path in Rust.

This is not a line-by-line port and it is not yet a complete replacement for Xray-core. It is a focused, embeddable client implementation designed around bounded queues, explicit resource limits and predictable memory usage.

The currently supported surface includes:

• TUN, SOCKS5 and HTTP CONNECT local inbounds;
• VLESS over TCP, WebSocket, HTTPUpgrade, gRPC and XHTTP;
• XHTTP packet-up, stream-up and stream-one over HTTP/1.1, HTTP/2 and HTTP/3;
• TLS, REALITY and xtls-rprx-vision;
• UDP and XUDP;
• domain/IP routing, DNS, FakeIP, geosite.dat and geoip.dat;
• iOS integration through SwiftPM and XCFramework;
• Android integration through an AAR published on Maven Central.

The current synthetic process-level benchmarks were run on an Apple M3 Pro:

• idle RSS: 3.84 MiB for xray-rust versus 28.1 MiB for Xray-core;
• 1,000 held SOCKS flows: 18.3 MiB versus 79.9 MiB;
• VLESS + REALITY + Vision throughput: 14.3 Gbps versus 13.7 Gbps.

The complete methodology and caveats are available in the benchmark results. The published comparison currently pins Xray-core v26.5.9 and should be treated as a reproducible snapshot rather than a claim about every Xray release.

The original practical result for me is that the Rust tunnel remains within the iOS memory budget in the profiles I use. I would now like to test it across more devices, configurations and real-world traffic patterns.

Important limitations:

• no VMess, Trojan, Shadowsocks or WireGuard yet;
• no server-side VLESS;
• only the documented subset of Xray configuration is supported;
• the project has not received an independent security audit;
• it is unofficial and is not affiliated with XTLS or Xray-core.

Prebuilt mobile packages and integration examples are available here:

• Core: github.com/aimalygin/xray-rust
• Mobile SDK: github.com/aimalygin/xray-rust-mobile
• Compatibility matrix: docs/config-compatibility.md

I am primarily looking for:

1. People who can reproduce the iOS memory issue with xray-core or libXray.
2. iPhone/iPad testers, especially with XHTTP/HTTP2 and bursty applications.
3. Maintainers of mobile Xray clients interested in testing an alternative backend.
4. Protocol and security reviewers willing to inspect the implementation.

I am not selling a VPN service. This is an open-source client core and mobile SDK.

Feedback about missing configurations, interoperability problems and useful mobile test scenarios would be very welcome.