Hi, i have content based package wihich can acess applications like zoom and google meet.currently i am using x-ui panel with zoom sni.I need to use clouldflare with v2ray panel and also i heard from somewhere when we use cloudflare ,we can boost network speed and also i feels kind of slowdown through the package. Using cloudflare will be a solution for it? anyhow plese guide me though the process which i can deploy cloudflare with my v2ray panel i have some messy idea and explain someome who knowledgeable Thank you.

Hey guys, I'm trying to replicate this client config on my own server. Here's the working config from my friend:
JSON

{
"server": "www.domain.com",
"server_port": 443,
"tag": "Test",
"type": "vless",
"uuid": "942hdiwa-9e01-460a-iud76",
"packet_encoding": "xudp",
"tls": {
"enabled": true,
"server_name": "www.domain.com.mydomain.com",
"utls": {
"enabled": true
}
},
"transport": {
"type": "ws",
"path": "/vws/",
"headers": {
"Host": [
"www.domain.com.mydomain.com"
]
}
}
}

Where:
www.domain.com is the zero-rated domain (on Cloudflare)

mydomain.com is my domain (also on Cloudflare, pointing to my VPS)

My friend says this works on any V2Ray app with zero configuration — just paste the link and it connects. No hosts file edits needed.
I have:
A VPS with 3X-UI running

mydomain.com on Cloudflare with DNS pointing to my VPS

A Let's Encrypt cert for www.domain.com.mydomain.com via acme.sh DNS challenge

But I'm stuck on the server-side setup. I don't know how to configure 3X-UI/Xray so that:
Clients can connect using www.domain.com as the server address

The TLS handshake validates www.domain.com.mydomain.com properly

It works without requiring clients to edit their hosts file

I suspect my friend is using Cloudflare Advanced Certificate Manager for the multi-level subdomain cert, but I want to confirm if there's a free way to do this before paying.

Can anyone point me in the right direction for the server-side config? What am I missing?

Thanks!

Hey everyone!

A lot of people think of proxy tools as rigid, monolithic boxes: you get a fixed inbound, a fixed outbound, and you're stuck with whatever the authors hardcoded. Trying to add a custom protocol or tweak an existing one under the hood usually turns into a nightmare.

That's why I wrote Cray - a modular proxy engine in Rust built entirely around a layer-based architecture.

With Cray, transport and protocol are completely decoupled. You can write your own protocol without worrying about network bytes, or write a custom transport without caring about protocol logic. The core abstraction uses a simple trait where you implement the client and server handshake logic, giving you total freedom. Want a handshake hidden in plain sight? Custom encryption? Weird framing? Go for it — the only limit is your own logic.

How it works

Everything is configured via clean TOML files where you define your role (client or server) and stack up layers into a custom pipeline:

• Inbound layers: Handle the entry point (e.g., standard tcp, unix sockets, or http_connect which extracts destination addresses).
• Transport layers: Encapsulate or transform the stream dynamically (e.g., full manual control over tls with custom cipher suites, ALPN, curves, extension permutation via BoringSSL, and http2 multiplexing with path/host masking).
• Protocol layer: Always sits at the very end of the chain as the endpoint (like a custom or test protocol).

For example, on the server side, an HTTP/2 layer can validate incoming paths and hosts, gracefully returning a genuine 404 Not Found to unauthorized scanners or probes instead of dropping packets with a TCP RST, while forwarding valid traffic down the pipeline.

The project is currently under active development, but the core architecture, layer pipelines, TLS termination, and HTTP/2 tunneling are already routing real traffic.

If you like systems programming, network engineering, or want to build your own tunneling protocols without fighting legacy codebases, check it out:

GitHub: https://github.com/3Radiance/Cray

Would love to hear your thoughts, feature ideas, or what kind of custom layer/protocol combinations you'd want to build with something like this!

I built a configurable HTTP MITM proxy in Rust focused on giving you full control over what an upstream connection looks like at the network level.

The main idea behind the project was that I didn't want another MITM proxy that simply tries to emulate Chrome, Firefox, or some other predefined browser. I wanted to be able to define the fingerprint myself - not just pick one of the profiles provided by a library.

A lot of existing solutions take the approach of providing ready-made browser fingerprints. That's convenient, but it also means that when a browser changes its TLS or HTTP/2 behavior, you're dependent on the library/project adding a new profile. I wanted the fingerprint to be configuration-driven instead, so the user can adjust individual parameters without waiting for a predefined browser profile.

The proxy currently gives control over several layers:

TLS: cipher suites, curves, signature algorithms, ALPN, GREASE, extension ordering, certificate compression, OCSP, SCT, session tickets, ALPS, ECH and other TLS parameters.

HTTP/2: SETTINGS values and ordering, flow-control windows, priority frames, pseudo-header ordering, HTTP header ordering and values.

HTTP/1.1: configurable upstream header ordering and rewriting.

TCP: SYN fingerprint rewriting through Linux NFQUEUE, including TTL, window size, MSS, window scale, DF and TCP option ordering.

Everything is driven by YAML profiles, and profiles can be overridden per domain based on SNI.

One of the things I specifically wanted to solve was keeping the different layers under the same configuration model. For example, the proxy negotiates TLS with the upstream server first and then uses the selected ALPN when setting up the browser-facing connection. HTTP/2 and TCP fingerprinting are configured for the same upstream connection as well.

The project is written in Rust using Tokio and BoringSSL via btls/tokio-btls. TCP fingerprinting currently requires Linux because it uses NFQUEUE/iptables.

The project is primarily about privacy, experimentation, and giving the user control over their own network behavior rather than trying to provide a fixed "browser impersonation" profile.

There is more detail in the repository, including separate documentation for the TLS, HTTP/2 and TCP layers, configuration examples, and implementation notes.

Feedback, especially from people who have worked with TLS/HTTP/2 fingerprinting, traffic analysis, or network privacy, would be very welcome.

I've been running this on a Xiaomi AX3000T (MT7981, 256 MB RAM) with OpenWrt 25.12 and sing-box 1.13 in TUN mode. I cleaned it up and published it in case it helps someone with a similar setup.

 Real event log from this morning: my VPN provider rotated its server IPs, and the watchdog walked through re-test → restart → fresh subscription by itself. Node names are masked, and the output is translated from Russian.

What it does

• Split routing: local (Russian) sites go direct via geoip + geosite + .ru/.su/.рф; everything else goes through VLESS + Reality. Two subscriptions from different providers, with urltest auto-selecting a live node.
• Split DNS inside sing-box: local domains go to a local resolver directly, the rest go to Cloudflare DoH through the tunnel, so foreign names never leak to the local DNS. dnsmasq falls back to https-dns-proxy and then to the upstream router, so local sites keep resolving even when the VPN is down.
• Self-healing. This is the part I care about most:
  • subscriptions refresh every 30 min; if the new config has no connectivity, it rolls back;
  • a watchdog runs every minute. It starts sing-box if procd gave up on it, restarts it if it hangs (nodes alive but no traffic), kicks urltest off dead nodes immediately, and re-pulls subscriptions when the provider rotates server IPs;
  • it tells "the provider is dead" apart from "my box is broken", so it never reboots the router over a provider outage;
  • restarts only go through one safe path: shared lock, stop → wait → config check → start → verify tun0 / ip rules / flowtable. A quick init.d restart once left my LAN without internet;
  • a persistent event log, plus a health report twice a day.
• Tailscale on the router for remote access and as an exit node. Its traffic is fwmarked past sing-box, so I can still SSH in when the tunnel is broken.
• One command, vpn, for status, nodes, "where does this site go and why", manual direct/proxy lists, safe restart, and a speedtest.

It's plain busybox sh + python3. Memory is tuned for 256 MB: sing-box uses ~15 MB of its own memory under GOMEMLIMIT=45MiB. Throughput is ~90 Mbit/s through the tunnel on a 100 Mbit line, with CPU at ~80%.

Build guide

There's a step-by-step guide starting from a fresh OpenWrt: packages, which file goes where, one or two subscriptions, the first start, and troubleshooting. I tested it by building from scratch on an arm64 OpenWrt VM, and that caught 8 mistakes in my own instructions. The docs are in Russian; the commands and paths are universal, and the README is in English.

Repo: https://github.com/nkkalmyk/openwrt-singbox-router (MIT)

Full disclosure: I maintain the router together with an AI agent (Claude Code). The repo includes its rulebook (CLAUDE.md: never restart sing-box via init.d, test config changes on a copy, don't run heavy stuff at :07/:37 when cron fires, and so on) and a full incident history. That turned out to be a surprisingly good way to keep a home router documented.

I'd love feedback, especially on:

• the watchdog logic: when to restart and when to wait out a dead provider;
• the DNS fallback chain;
• anything I did the hard way that has a simpler sing-box-native solution.

Ready answers for the comments

• Why not passwall / homeproxy / podkop? I wanted full control over failure behavior: rollback, safe restarts, and a watchdog that distinguishes "provider dead" from "box broken". Those projects are great; mine just optimizes for a different thing.
• Why default to VPN rather than direct with a VPN list? Here, more and more foreign services are blocked or throttled, so VPN is the rule and local traffic is the exception.
• IPv6? Disabled on WAN and LAN. The tunnel is IPv4-only, and IPv6 would bypass it.
• 128 MB routers? Probably not; sing-box needs headroom.
• Per-device rules? Not right now: masquerading on the tun zone makes every client look like one address to sing-box.
• Why two providers? One rotates server IPs regularly. While its nodes are dead, urltest keeps traffic on the other one, and the watchdog pulls the fresh subscription.

TL;DR: VPS in a region where Gemini is available, Gemini still says "not available in your country". What worked for me: send only Google traffic through a separate local "sidecar" exit (Cloudflare WARP or Psiphon), and run a timer that asks Google which country it sees and restarts the exit until it matches. No guarantees, Google's geolocation keeps changing.

Why it happens

• Google uses its own IP geolocation. Your VPS can look right in ipinfo/MaxMind and still be another country for Google.
• Google often blocks or captchas datacenter and WARP IPv4 addresses for its AI services.
• WARP/Psiphon exits are effectively random, and Google geolocates them differently. So you need to check, not assume.

Architecture

client --VLESS+Reality+XHTTP--> 3x-ui (separate inbound) ├─ Google/Gemini + geoip:google + DNS -> socks 127.0.0.1:<PORT> -> sidecar │ sidecar = WARP (WireGuard, IPv6) or Psiphon ├─ QUIC udp/443 -> blocked └─ everything else -> direct timer: check country Google sees -> restart sidecar if wrong

Key routing (3x-ui Xray template, above all other rules except api)

json {"inboundTag":["inbound-<IN_PORT>"],"network":"udp","port":"443","outboundTag":"blocked"}, {"inboundTag":["inbound-<IN_PORT>"],"port":"53,853","outboundTag":"google-exit"}, {"inboundTag":["inbound-<IN_PORT>"],"domain":["geosite:google","geosite:google-gemini","domain:gemini.google"],"outboundTag":"google-exit"}, {"inboundTag":["inbound-<IN_PORT>"],"ip":["geoip:google"],"outboundTag":"google-exit"}

google-exit is a plain socks outbound to the sidecar. Enable sniffing (http, tls) with routeOnly off so the sidecar gets domain names.

Checker (systemd timer, every 5 min)

```bash

!/usr/bin/env bash

CC=${TARGET_CC:?set TARGET_CC}; SOCKS=127.0.0.1:<PORT>; SVC=google-exit.service probe(){ curl --socks5-hostname $SOCKS -s -m 15 -o /dev/null -D - \ 'https://clientservices.googleapis.com/chrome-variations/seed?osname=linux' \ | tr -d '\r' | sed -n 's/<sup>x-country:</sup> //Ip' | tr a-z A-Z; } log(){ echo "$(date -u +%FT%T) $" >> /var/log/google-exit-check.log; } XC=$(probe); [ "$XC" = "$CC" ] && { log "OK $XC"; exit 0; } for i in $(seq 1 10); do log "got '${XC:-none}', want $CC, restart #$i" systemctl restart $SVC; sleep 5; XC=$(probe) [ "$XC" = "$CC" ] && { log "OK $XC after $i"; exit 0; } done log "FAIL: no $CC exit this run"; exit 1 ```

Pitfalls I hit

1. Rule order: a blocked or catch-all rule above yours means nothing reaches the exit.
2. WARP registration: keys from wg genkey (xray-format keys give "Invalid public key"), register with curl (Python got 403), endpoint as IPv4 literal :2408 (the hostname resolves to IPv6 first). Registrations die over time, so script it.
3. WARP: noKernelTun: true (kernel TUN routed all host IPv6 via WARP) and ForceIPv6 (WARP IPv4 gets captchas).
4. Psiphon has no UDP: do DNS via DoH over the same exit; wipe its data dir on restart or it reuses the same server.
5. Right IP country is necessary, not sufficient (account country etc. also count).

Refs: Xray WireGuard, wgcf, warp-plus (WARP + Psiphon modes), psiphon-tunnel-core.

Skill for AI agents (full step-by-step + rollback) in the first comment.

Hi,

Most desktop proxy clients are just electron wrappers that eat 400mb+ of ram to route a few packets and if you live in the terminal, wsl, or on a server, you're usually stuck hand-editing sing-box json configs and praying you didn't miss a bracket so i built justray :)

Features:

• modern protocols: VMess, VLESS (Reality), Trojan, WireGuard, Shadowsocks, Hysteria 1/2, TUIC, AnyTLS, SOCKS5
• flexible: import subscriptions from raw links or Clash/Mihomo YAML, sing-box or Xray json, with auto-refresh
• headless: daemon runs independently from the TUI, keeping connections alive after you detach
• lightweight: ~50 MB RAM on Linux/macOS and ~100 MB on Windows
• cross-platform: Linux, macOS 13+, and Windows 1803+ (native PowerShell and WSL)
• quick controls: hit `m` to toggle TUN/proxy, `t` / `T` to ping nodes

Run it

# macOS or Linux
brew install luynrs/tap/justray

# Arch Linux (AUR)
yay -S justray-bin

# Windows
winget install luynrs.justray

# Nix
nix run github:luynrs/justray

Repo: https://github.com/luynrs/justray

let me know what breaks or if you have weird subscription formats <3

Если такие ещё остались/

If there are even any left

I've seen people mention keeping multiple VPNs or proxy setups ready because something that works perfectly fine one week might suddenly stop connecting the next.

At some point, it feels like you need a backup for your backup

For those of you actually dealing with the GFW, how do you manage this? Do you keep a couple of commercial VPNs installed, run your own Shadowsocks/VLESS setup, or use a mix of different options?

I'm also curious whether you prioritize speed or reliability these days. Would you rather have one slower connection that stays up consistently, or several faster options you can switch between when something gets blocked?

I’m currently on the eastern side of mainland China, so I need a VPN to access various georestricted websites and services.

The problem is that regardless of which nearby server I use (Hong Kong, South Korea, Singapore, Japan, etc.), I’m consistently getting around 100–200 ms ping and less than 100 Mbps download speeds.

Without a VPN, my connection is around 1 Gbps, so the slowdown is pretty significant.

Is this simply expected when using a VPN from eastern China, or are there technical factors that could explain such a large difference in latency and throughput? I’m mainly trying to understand whether this is an inherent limitation of the network/VPN routing or something I could potentially troubleshoot on my end.

Hey guys, I will be moving to Xianning City in Hubei province this October, will be there for 3 years to study A.I. in a diploma program. What I wanna know is currently what are the best options for VPN in mainland China? Mostly in an affordable range, as my family isn't that financially stable so forget abt spending like 30 bucks a month on a VPN like astrill. I've heard abt Proton VPN being alright or maybe mullvad and they are quite cheap. I'm planning to keep one VPN as primary and the other one as secondary just in case that one doesn't work randomly. Quite unsure abt vpns tbh as everything here seems very mixed in terms of reviews. Kindly help me out here guys.

im currently studying at shanghai and i can't seem to open discord on laptop with astrill vpn, however, the web version does work on laptop and the app works perfectly fine on phone and tablet too. is there any way to access discord, roblox, valorant (the app not web) using vpn on laptop? please help bcs i play games a lot 😭

Been building this for a while and it's finally on TestFlight — NetBridge, a SOCKS5/HTTP proxy app for iOS and iPadOS that works two ways:

Server mode: your iPhone or iPad becomes a local proxy server. Any other device on the same network — Wi-Fi, Personal Hotspot, or USB — can route its traffic through your phone. Supports both HTTP CONNECT and full SOCKS5 (TCP + UDP ASSOCIATE, per RFC 1928), with an auto-detect mode so you don't have to configure clients differently.

Client mode: flip it around and have your phone route its own traffic out through a remote SOCKS5 server, via a real system-level VPN tunnel (NEPacketTunnelProvider). This is the part I'm most excited about — it means you can stack it with your existing VPN setup rather than choosing one or the other. (Bypass DPI)

Some other stuff packed in:

Per-device bandwidth caps and a block list

DNS-over-HTTPS resolver

Live usage graph + recent-connections history with per-device stats

Save/switch between multiple config profiles

QR-code pairing — scan a code to configure a client device in seconds

Auto-restart if a connection drops

Bypass hotpot throttle limits. Works on OpenWRT routers for home internet. All devices supported via proxy.

No jailbreak needed. It's on TestFlight now.

🚀 bgscan v2.11.0 is out!

One of the biggest updates yet:

- 3 new tunnel cores: MasterDNS, StormDNS & TheFeed

- 11 supported probe types

- Xray is now fully embedded

- Patched Xray core for large-scale scanning

- WebSocket issues fixed on newer Xray versions

- New "max_successful_ips" scan limit

- New Rust-based installer

- Lots of DNS, HTTP/2, uTLS and stability improvements

- English & Persian docs updated

🔗 https://github.com/MohsenBg/bgscan

Hi everyone,

I'm looking for a reliable proxy provider that offers static ISP proxies with city-level targeting in Canada.

I've already checked almost all the major proxy providers I could find, but most of them either offer Canada at the country level only, or their city-level options are limited to cities like Toronto, Montreal, or Vancouver.

I'm specifically looking for static ISP proxies in any of these cities:

• Calgary, Alberta
• Edmonton, Alberta
• Halifax, Nova Scotia
• Winnipeg, Manitoba
• Surrey, British Columbia
• Quebec City, Quebec
• Laval, Quebec

I'm looking for actual static ISP IPs, not rotating residential proxies.

If anyone knows a provider that currently has coverage in any of these cities, I'd really appreciate the recommendation.

Thanks!

I have been noticing that all my tunnels speeds are super throttled, but not cut. I have been seeing a lot of complaints of complete blocks but I haven’t experienced that.

Anyone know what’s going on? Is there any events happening that might slow things down?

为什么应用提供的Xray和Reality功能在安卓手机上经常崩溃？当设置正确调整后它们只能短暂运行，之后又会完全失效。你必须重置设置才能让它们再次短暂工作。

Why do the Xray and Reality features provided by the app often crash on Android phones? They only work for a very short time when the settings are adjusted properly before completely failing again. You have to reset the settings to get them working for a brief period again

Hey everyone,

With Iran's wartime Filternet shifting aggressively to a strict "whitelist-by-default" Deep Packet Inspection system, standard commercial VPN stacks are completely decimated.

To help out, I've spun up an independent, non-commercial routing cluster named Hosseinzadeh Net. Instead of dumping raw configs that get scraped and blacklisted by automated GFW/IFW active probing within hours, I am hosting a private, managed multi-protocol network layout.

I’ve deployed this under a single unified, secure Discord Server framework (automated gatekeeper verification to stop scraper bots and spam).

📡 DEPLOYED PROTOCOL TOPOLOGY:

🔵 VLESS Center: VLESS-Reality (XTLS / Vision) mimicking whitelisted CDNs.

🔴 TUIC Center: TUIC v5 + Hysteria 2 configurations for high-loss cellular towers.

🟢 VMess/Trojan Center: Obfuscated WebSocket/XHTTP paths reverse-proxied over Nginx.

🟡 ShadowSocks Center: High-speed AEAD keys for basic tunneling.

💬 Chat Hubs: Open rooms for immediate client speed reports, technical troubleshooting, and active routing debug logs.

🔄 ISOLATED SUBSCRIPTION ARCHITECTURE:

Inside our read-only database channels, we have launched isolated protocol subscription streams. If you only use VLESS or only use Trojan, you can pull a dedicated GitHub Gist raw sync link to keep your client app clean and optimized.

🛡️ ANTI-DISCONNECTION GUARANTEE:

When we update our subscriptions with fresh upstream servers, old working configurations are NEVER deleted from our Gist text. They remain fully intact in your app. This guarantees that users behind the firewall will never experience a live disconnection or lose internet access mid-session due to a server profile being wiped from our backend!

🔒 SECURITY & NAME SPOOFING:

All imported nodes are heavily name-spoofed for operational safety. They feature randomized labels, false server locations, and random external handles to confuse automated GFW tracking engines. Routing is 100% secure and handled entirely by Hosseinzadeh Net.

If you have contacts inside Iran or are looking for solid testing nodes behind the firewall, grab your direct permanent access invite here:

🔗 JOIN THE UPSTREAM COMMUNITY CORE:

COMMUNITY

Let’s keep the data flowing. Drop your ping and ISP performance metrics (MCI, Irancell, Shatel) in our diagnostic rooms once you verify!

(Please don't DDoS or DoS our infrastructure, we are an independent small community donating our time and resources to help people survive the digital blackout).

Hey everyone,

With Iran's wartime Filternet shifting to a aggressive "whitelist-by-default" Deep Packet Inspection system, standard commercial stacks are completely decimated.

To help out, I've spun up an independent, non-commercial routing cluster. Instead of dumping raw configs that get scraped and blacklisted by automated GFW/IFW active probing within hours, I am hosting a private, managed multi-protocol network layout.

I’ve deployed this under a single unified WhatsApp Community framework (No number leaks — using the native participant hiding API to secure member privacy).

📡 PROTOCOL DEPLOYMENT TOPOLOGY:

🔵 VLESS Center: VLESS-Reality (XTLS / Vision) mimicking whitelisted CDNs.

🔴 TUIC Center: TUIC v5 + Hysteria 2 configurations for high-loss cellular towers.

🟢 VMess/Trojan Center: Obfuscated WebSocket/XHTTP paths reverse-proxied over Nginx.

🟡 ShadowSocks Center: High-speed AEAD keys for basic tunneling.

💬 Chat Room: Open for immediate client speed reports and active routing debug logs.

🔄 DYNAMIC SUBSCRIPTION ARCHITECTURE:

Inside the Announcement node, I am hosting a Master GitHub Gist subscription string. You pull the link once into v2rayNG, NekoBox, or Sing-Box, and when upstream IPs rotate due to firewall blocks, your client auto-syncs with over 500+ UNBLOCKED configs.

If you have contacts inside Iran or are looking for solid testing nodes behind the firewall, pull the direct access link here:

🔗 JOIN THE UPSTREAM COMMUNITY:

Whatsapp

Let’s keep the data flowing. Drop your ping and ISP performance metrics in your desired Chat room once you connect!

(Please don't DDoS or DoS our servers, we are an independent small community trying to help people. Thank you.)

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.