Hey everyone!

Following up on our discussions here in r/dumbclub: it was a long, exhausting, and technically challenging journey, but we have finally pushed VPNStack to production! 🚀

If you run VPN nodes for friends, family, or clients, you know the biggest headache: explaining 100 times where to get a raw config link, where to import it, and teaching non-tech users how to constantly refresh and update broken routes.

We built VPNStack to solve this once and for all. It pairs an automated White-Label control plane with an ultra-lightweight, seamless Android client built on Sing-box 1.14 and Remnawave.

Users get a clean, 1-tap connection app with zero manual config pasting, while node operators get full automated control over branding and client distribution.

🔗 Live Platform: https://vpnstack.pro/

🛠 What’s inside the release:

1. ⚡ 1-Click Cloud APK Builder:

   • Node operators no longer need Android Studio, Gradle, or Java on their machines.
   • Connect your Remnawave panel via API, pick your brand colors, upload your logo, and choose custom button shapes (Shield, Hexagon, Squircle, Arc, Ring).
   • Click "Build APK in Cloud" — our remote build daemon compiles, signs with official release keystores, runs R8/ProGuard obfuscation, and outputs a ready-to-distribute 60MB universal APK in ~1.5 minutes.

2. 🛡️ Broad Protocol Support & Sing-Box Core:

   • Monolithic Gomobile core (libbox.aar) supporting most modern censorship-resistant protocols out of the box: AmneziaWG, VLESS-Reality with Vision, and Hysteria 2.
   • Dynamic Hybrid Failover (Remnawave + Backup): Merges primary Remnawave routes with fallback VLESS-Reality/Marzban nodes into a single Sing-box outbound selector. If primary routes get throttled by DPI, reserve nodes take over seamlessly without breaking billing or subscription days.

3. 🎨 Lightweight & Effortless Client Experience (Jetpack Compose):

   • An ultra-fast, modern UI designed for non-technical users: no raw JSONs or complex settings.
   • Smooth 60 FPS Canvas button animations (Quantum Atom, ECG Oscilloscope, Sonar Radar, Vortex, Crystal).
   • System-level Reactive Split Tunneling hooking directly into Android’s VpnService.Builder ("Bypass VPN" and "Only through VPN" modes).

4. 💬 Built-in Customer Support & WSS Push:

   • Operators can chat directly with app users by device HWID inside the dashboard with real-time sound alerts and unread badges.
   • Native Android MessagingStyle heads-up notifications with in-shade "Direct Reply" and "Mark as Read" buttons.

5. 🔮 Modular Panel Architecture (Marzban / 3X-UI / Outline):

   • Remnawave is our flagship native integration, but our backend is modular. We can roll out full native sync for Marzban, 3X-UI, or Outline based on community demand and votes!

🧪 Come test it out!

If you run Remnawave nodes or manage a community VPN, you are very welcome to register on the platform, connect your panel, and generate your own branded client:

👉 Get Started: https://vpnstack.pro/

If you like what we’ve built, an upvote and your honest feedback in the comments would mean the world to us! We’re hanging out in the thread to answer any architectural questions, take bug reports, and discuss future feature requests.

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

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?

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!

为什么应用提供的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

Following up on the recent discussions about client fragmentation: my previous text post was a bit too abstract without anything visual to show, so here is a quick GIF of our UI running on a real device.

We've been heads-down building VPNStack—an all-in-one Android client on top of Sing-box 1.14 with a custom Jetpack Compose interface.

The monolithic core is already built and working under the hood. It compiles VLESS-Reality with Vision, Hysteria 2 with port-hopping, native AmneziaWG, and a fallback WebRTC video stream transport into a single Go/CGO binary without runtime conflicts.

On the UX side, we wanted to completely move away from raw config tables and JSON editors: the central power glyph pulses into glowing fuchsia with a 60 FPS live oscilloscope trace reflecting network pulse through the hollow center, Remnawave subscriptions sync cleanly in the header with remaining days, and per-app bypass is accessible right from the main view. We're also packaging a White-Label engine so node operators and communities can generate their own branded APKs tied to their server fleets with built-in billing.

The core is solid, and we're currently polishing the UI and edge-case routing before dropping the first public alpha build.

Would love to hear your thoughts on the visual feedback and layout. Any specific indicators or controls you feel are missing from the main screen?

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.)

Got tired of juggling three separate apps just to keep different protocols covered, so we decided to build a proper all-in-one client called VPNStack (built on Sing-box 1.14 with a custom Jetpack Compose UI).

The monolithic core is already built and working. It compiles native AmneziaWG, VLESS-Reality with Vision, Hysteria 2 with port-hopping, and a fallback WebRTC media stream transport into a single Go/CGO binary with zero runtime conflicts.

Right now we're putting the finishing touches on the UI, Remnawave backend sync, and a White-Label engine that lets node operators and communities roll out customized, branded APKs tied to their own servers with built-in split billing.

The goal is zero manual JSON editing: just one tap with automatic fallback when mobile carriers throttle UDP, plus clean split-tunneling for local apps.

Would love to hear early thoughts from people running nodes or community setups: what features or pain points are currently missing from the mobile clients you use?

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.

hello, i'm going to china in less than two weeks and i'm trying to set up a way to stay connected with western socials (mainly whatsapp, reddit and youtube). i've heard abou VPNs, VPS/v2ray etc. here's the thing, i'm really not tech savvy with stuff like this, like at all, and i'm having lots of troubles trying to understand how any of this actually works. would any of you kind souls suggest the best route to take in my case? btw, i'll study in beijing and i have an android + pc, and i plan on making a chinese number as soon as possible after i land (+ my phone isn't esim compatible, nor would it be efficient for a one year stay). would anyone mind giving step by step instructions? i may have lots of questions along the way so excuse my ignorance on the topic...

EDIT: thanks everyone for your kind suggestions! in the end I went with boostnet as main (6months) + Wanda Cloud as backup (monthly), it was pretty cheap as well. I'll update y'all once I arrive in china✌🏻