Multipath proxy that bonds multiple xray tunnels into one reliable, low-latency SOCKS5 endpoint.
For when you absolutely cannot afford a disconnect. Crypto mining, important video calls, trading, remote work — anything where one dropped connection ruins your day. XPlex keeps your internet alive by sending your data through multiple paths at once. If one path dies, the others cover it instantly. The cost: 2-3x more bandwidth usage.
Every byte you send is duplicated across N parallel xray paths. The fastest copy wins; the rest are dropped. If a path dies mid-stream, the others keep delivering — zero packet loss, zero reconnects visible to your application.
┌─── xray 1 ───┐
App ──► SOCKS5:2080 ──┼─── xray 2 ───┼──► VPS (xplex server) ──► destination
└─── xray 3 ───┘
- Client (
xplex client): runs an embedded Xray-core with one outbound per share link inxrays.txt, opens a long-lived encrypted tunnel pool to your VPS, and exposes a local SOCKS5 port. Any app that connects gets multipath reliability transparently. - Server (
xplex server): accepts tunnel connections, demuxes by session, dials whatever destination the client requested (full forwarding — works for browsing, mining, anything). - Adaptive duplication: a controller watches per-tunnel win rates and demotes slow tunnels to "shadow" (receive-only) to save bandwidth. Shadows get promoted back if conditions change.
- PSK encryption: all traffic between client and server is encrypted with ChaCha20-Poly1305 using a pre-shared key. Xray operators cannot read or tamper with your data.
None. Xray-core is compiled into the xplex binary, so there is nothing to download, unpack, or point a path at:
your-folder/
├── xplex (or xplex.exe on Windows)
├── config.json
└── xrays.txt
No xray executable, and no geoip.dat/geosite.dat either — the generated routing rules match on inbound tags and never touch geo data.
Older configs that set
xrayBinstill load; the field is ignored and logs a note.
# Generate a shared secret (run once, paste into both configs)
xplex gen-key
# Server (on your VPS)
xplex server --config config.json
# Client (on your local machine)
xplex client --config config.jsonThen point any SOCKS5-capable app at 127.0.0.1:2080.
{
"client": {
"listen": "2080",
"server": "your-vps.example.com:7000",
"xrayLinks": "xrays.txt",
"xrayBasePort": 1080,
"psk": "your-64-char-hex-key-here"
}
}{
"server": {
"listen": "7000",
"psk": "same-64-char-hex-key-here"
}
}One share link per line. Blank lines and # comments are ignored.
vless://uuid@server1:443?encryption=none&security=tls&sni=cdn.example.com&type=xhttp&host=cdn.example.com&path=/p&mode=auto#name1
vless://uuid@server2:2092?encryption=none&security=reality&sni=play.google.com&fp=chrome&pbk=PUBKEY&sid=SHORTID&type=tcp#name2
hysteria2://password@server3:8443?sni=server3.example.com&obfs=salamander&obfs-password=SECRET#name3
trojan://password@server4:443?security=tls&type=ws&host=cdn2.example.com&path=/ws#name4
Supported protocols: vless:// (including REALITY and VLESS Encryption / mlkem768x25519plus), trojan://, hysteria2:// / hy2:// (with Salamander obfuscation), ss:// (plus v2ray-plugin).
Supported transports: raw/tcp (with HTTP header fronting), xhttp/splithttp, ws, httpupgrade, grpc.
Not supported: vmess://, tuic://, and the kcp/quic transports. These fail with an explicit error rather than connecting in a degraded state.
Before wiring up a server, verify each link parses and actually carries traffic:
go run ./tools/linkcheck -xrays xrays.txtPORT STATE LATENCY LINK
1080 OK 929ms vless://server1:443 (name1)
1081 FAIL 5.004s hysteria2://server3:8443 (name3)
└─ read: connection reset by peer
# Go version required is the one in go.mod
CGO_ENABLED=0 go build -trimpath -ldflags "-s -w" -o xplex ./cmd/xplexXray-core is a normal Go dependency, so this is the whole build. Note that linking it in makes the binary noticeably larger than before (tens of MB rather than a few).
Or just grab a pre-built binary from Releases.
| OS | Architectures |
|---|---|
| Linux | amd64, arm64, armv7, armv6, 386, mips, mipsle, mips64, mips64le, riscv64 |
| Windows | amd64, arm64, 386 |
| macOS | amd64 (Intel), arm64 (Apple Silicon) |
| FreeBSD | amd64, arm64 |
| OpenBSD | amd64 |
Releases are automated via GitHub Actions — push a tag like v1.0.0 and binaries for all platforms are built and published automatically.
cmd/xplex/ CLI entrypoint (client, server, gen-key subcommands)
internal/
mppool/ Long-lived tunnel pool with auto-reconnect + Active/Shadow states
mphub/ Session demux + per-tunnel win tracking
mpfront/ Local SOCKS5 frontend (client side)
mpserver/ Tunnel acceptor + destination dialer (server side)
mpadapt/ Adaptive duplication controller
mpcrypto/ ChaCha20-Poly1305 AEAD frame encryption
mpframe/ Wire format (type + session ID + seq + payload)
mpdedup/ Per-session reorder + dedup buffer
mpconfig/ JSON config loading + flag merging
config/ Xray share-link parser + JSON config generator
xraycore/ Embedded Xray-core lifecycle (in-process, no child process)
links/ xrays.txt reader
socks5/ SOCKS5 client dialer
probe/ TLS-handshake latency probe
stats/ Rolling P50/P90/success-rate tracker
monitor/ Periodic health-check loop
runner/ Per-link SOCKS5 endpoint descriptor + readiness check
testutil/ Shared test fakes
tools/
linkcheck/ Verify every link in xrays.txt parses and passes traffic
- Zero visible packet loss: if any one tunnel is alive, bytes flow.
- Latency = fastest path: you always get the best of N tunnels per byte.
- Encrypted end-to-end: xray operators see only random bytes.
- Tamper-proof: Poly1305 MAC rejects any modification.
- Self-healing: dead tunnels reconnect with exponential backoff; sessions are killed cleanly if all tunnels die so apps can retry.
- Bandwidth-aware: adaptive controller reduces duplication when paths are stable.
MIT