OpenWRT VLESS Client Configuration: Route All Traffic via Xray
Router-level proxy means every device on your network - smartphones, TVs, IoT - routes through the proxy without any client software. This guide covers xray-core and sing-box installation on OpenWRT, VLESS Reality config, routing rules, and DNS leak prevention.
Complete OpenWRT proxy setup using xray-core or sing-box with VLESS Reality. Covers prerequisites, package installation, router VLESS config JSON, iptables routing rules, DNS leak prevention, and how to verify the exit IP.
Prerequisites
You need an OpenWRT router with at least 16 MB flash and 128 MB RAM. Check your router model on openwrt.org to confirm compatibility. The guide was tested on OpenWRT 23.05 with a GL.iNet router.
Required packages: xray-core (or sing-box as alternative), iptables-nft, dnsmasq-full (replace dnsmasq). SSH access to your router is required.
Install xray-core on OpenWRT
SSH into your router: ssh root@192.168.1.1. Install xray-core with opkg update && opkg install xray-core. If xray-core is missing from your build's opkg repository, grab the correct arm or mipsle binary from the Xray-core GitHub releases and drop it in /usr/bin/xray.
Create the config directory: mkdir -p /etc/xray. The main config file will be /etc/xray/config.json.
VLESS Client Configuration
Create /etc/xray/config.json with inbound and outbound blocks. The inbound handles local traffic - SOCKS5 on port 1080 for manual use, transparent proxy on port 1081 for capturing routed traffic. The outbound connects to your VLESS mobile proxy using the OpenWRT VLESS configuration string from your Proxy Poland dashboard.
config.json structure
{ "inbounds": [{"port": 1080, "protocol": "socks"}, {"port": 1081, "protocol": "dokodemo-door", "settings": {"followRedirect": true}}], "outbounds": [{"protocol": "vless", "settings": {"vnext": [{"address": "YOUR_SERVER", "port": 443, "users": [{"id": "YOUR_UUID", "encryption": "none", "flow": "xtls-rprx-vision"}]}]}, "streamSettings": {"network": "tcp", "security": "reality", "realitySettings": {"fingerprint": "chrome", "serverName": "YOUR_SNI", "publicKey": "YOUR_PUBKEY"}}}] }Proxy Poland provides dedicated Polish 4G/5G mobile proxies with VLESS/Xray support. Real SIM cards, IP change once per minute, 99.9% uptime target.
Routing Rules with iptables
To intercept all TCP/UDP traffic and route through xray, add iptables rules. Create /etc/firewall.user with PREROUTING rules that redirect traffic to port 1081 (dokodemo-door) except for local and reserved IPs.
Add xray to startup: /etc/init.d/xray enable. Start the service: /etc/init.d/xray start. Check logs: logread | grep xray.
DNS Leak Prevention
Without DNS leak prevention, DNS queries handle the proxy and reveal your real location. Configure dnsmasq to forward all queries through xray's DNS: in /etc/dnsmasq.conf, set server=127.0.0.1#5300 and disable-systemd-resolved.
Add a DNS inbound to your xray config on port 5300 that forwards queries through the VLESS outbound. Check for leaks at proxypoland.com/tools/dns-leak-test - if the OpenWRT VLESS configuration is correct, all DNS servers should resolve to Polish IPs.
Verification
From any device on your network, visit proxypoland.com/tools/proxy-checker. Your IP should be a Polish mobile carrier IP. Run a speed test - you will typically see 20-40 Mbps through VLESS Reality on a capable router.
The opkg commands in this guide apply to OpenWrt 24.10 and older. OpenWrt 25.12.0, released in March 2026, replaced opkg with apk, so on a current image you install with apk update && apk add xray-core. The package name is unchanged: in November 2026 the 25.12.0 feed for aarch64_cortex-a53 listed xray-core 26.10.21. Other opkg commands in this guide need the same translation because apk takes different arguments, and the OpenWrt project publishes an opkg-to-apk cheatsheet for that. The steps above were tested on OpenWrt 23.05, so check them again on your own router after moving to 25.12.
Official sources
Frequently Asked Questions
Both support VLESS Reality. xray-core is more mature and widely documented. sing-box has a simpler JSON config format and better UDP performance. For most users starting out, xray-core is easier to find help for.
Encryption has a CPU cost. On older MIPS routers, you may see 10-20% throughput reduction. Modern ARM routers (GL.iNet Beryl AX, Banana Pi R4) handle VLESS Reality at full line speed. If speed is critical, use XTLS-Vision flow which offloads some processing.
Download the pre-compiled xray binary for your CPU architecture from github.com/XTLS/Xray-core/releases. Match the architecture: MIPS24kc for most older routers, ARM v7/v8 for modern ones. Place in /usr/bin/xray and chmod +x.
Yes. In the iptables PREROUTING rules, match by source IP or MAC address instead of routing all traffic. Example: add -s 192.168.1.50 to route only one device through VLESS while other devices use the regular internet.
Yes. Every Proxy Poland plan includes VLESS/Xray protocol access. You receive a VLESS Reality connection string with your subscription. The protocol runs on port 443 with Reality camouflage, making it resistant to deep packet inspection.
SSH into the router, run opkg update, then opkg install xray-core. On older OpenWRT releases (19.07 and below) xray-core is not in the default feed - add the v2ray feed manually or pick sing-box instead, which has wider package coverage. Confirm install with xray version. Configuration goes in /etc/xray/config.json or via the luci-app-xray-core LuCI module if installed.
Minimum 64 MB free RAM for xray-core idle, 128 MB+ recommended for sustained throughput. Routers with 32 MB total RAM (older TP-Link N-class) cannot run xray reliably. Modern routers with 256-512 MB (GL.iNet MT3000, Xiaomi AX3600 with OpenWRT) handle 100-200 Mbps VLESS encryption without saturating CPU. Sing-box is lighter (~30% less memory) if RAM is tight.
Use policy-based routing via the iptables/nftables rule that marks packets from specific MAC addresses or LAN IPs into a separate routing table that uses the xray TPROXY chain. The pbr (Policy Based Routing) LuCI app simplifies this - install with opkg install pbr-iptables, then in LuCI > Network > Policy Based Routing add a rule mapping a device's MAC to the xray interface. Other devices keep using the default WAN.
Yes if you enable the service: /etc/init.d/xray enable and /etc/init.d/xray start. The init script re-launches xray-core on every boot using /etc/xray/config.json. Verify after reboot with logread | grep xray to confirm clean startup. If using the LuCI module, the 'Enabled at startup' checkbox does the same thing under the hood.
LTE links typically use MTU 1428-1500 depending on carrier; with VLESS encapsulation overhead, set MTU 1380-1400 on the WAN interface to avoid fragmentation. Test with ping -s 1372 -M do [target] from a LAN client - if it succeeds, your effective payload size is healthy. Symptoms of wrong MTU: TCP connections open but stall on large transfers (TLS handshake completes, then site does not load).
Yes - that is the standard pattern. WAN handles direct internet for normal devices; the xray-core service listens on a local TPROXY socket and selectively routes flagged devices through the VLESS tunnel. From OpenWRT's perspective, VLESS is a separate egress that PBR rules can target. Use this to put a single home device (work laptop, IoT camera, IPTV box) on a Polish IP without touching the rest of the LAN.
Install vnstat (opkg install vnstat) and bind it to the xray virtual interface or the upstream WAN - vnstat -d shows daily totals. For real-time view use iftop -i [iface]. xray-core itself logs to /var/log/xray/access.log and error.log if logging is enabled in config.json - useful for spotting failed handshakes vs successful tunnels under load.