XKeen 2.0 on Keenetic/Netcraze: policies, DNS-over-VLESS, IPSET and DSCP — what changed

TrustMe · August 7, 2026, 9:53am

We already have on the forum an XKeen installation on Mihomo kernel and the Remnawave HWID subscription add-on. Both are about how to set it up. This material is about what changed afterward: on June 6 XKeen 2.0 was released, and some things were changed, making some old instructions outdated in places.

We break it down feature by feature: what appeared, why it’s useful, and what needs to be reconfigured.

Info:

Who is this even for. XKeen is a POSIX-shell utility that runs on a Keenetic router (in Russia the brand is renamed to Netcraze) to transparently proxy through Xray or Mihomo via the router. The point is that routing is solved on the router, not on every client. A TV, a console, a smart bulb, a guest laptop — none of them will ever get a sing-box client, but they will get the required route from the router.

For operation you need Entware on a USB drive with ext4 — without it nothing will work.

Change 1. User policies

Previously XKeen lived in one rigid Keenetic policy. Now in 2.0 there is a stated support for user policies — you create your own policy in “Connection Priorities”, assign the necessary devices to it, and XKeen operates with that policy.

Practical meaning: different groups of devices can be managed differently, without cobbling together workarounds. Plus, the built-in Keenetic policy “No Internet access” compatibility has been separately refined — previously combining them produced odd effects.

Change 2. DNS proxying and DNS-over-VLESS

This is arguably the most valuable. The usual scheme of “traffic through proxy, DNS through provider” is leaky: the list of domains you resolve remains with the provider, and DPI can easily see where you go.

XKeen 2.0 can proxy DNS (xkeen -dns), and the project wiki separately describes the scheme DNS-over-VLESS — when DNS queries go inside the same VLESS/Reality tunnel rather than a separate DoH.

The scheme boils down to three pieces of Xray config: dokodemo-door on a separate port with tproxy, a separate outbound with "protocol": "dns", and a routing rule that sends port 53 to this outbound:

{ "port": 53, "outboundTag": "dns-out" }

Warning:

The pitfall from the same wiki: many server configs block geoip:private, and that includes the system resolver 127.0.0.53. With such a rule, DNS-over-VLESS simply won’t work — you need to remove the rule or send that address to direct.

Security:

A note about the xkeen -dns mode: it works correctly for devices that are not in the XKeen policy, only if they do not have default DNS settings. Check the result not by feel but by watching where UDP packets actually go on port 53.

Change 3. IPSET and exclusion of Russian subnets

In 2.0 there is support for IPSET and the ability to exclude Russian IP subnets from proxying — this is chosen directly at the installation stage (step 7 of the installer).

There are four pairs (IPv4 + IPv6), and understanding who is responsible for what saves hours of debugging:

Set	What’s in it
`user_exclude` / `user_exclude6`	Your own addresses and subnets
`geo_exclude` / `geo_exclude6`	Russian subnets
`geo_override` / `geo_override6`	Exceptions to exceptions — what still should be proxied
`ext_exclude` / `ext_exclude6`	External applications should go here

Your addresses go into /opt/etc/xkeen/ip_exclude.lst, one entry per line, empty lines and comments are ignored.

Success:

A live scenario from the project FAQ: if you occasionally experience dropped connections, the authors explicitly say that Xray is not designed for streaming traffic. It’s fixed by adding an IP service with a /32 mask to ip_exclude.lst — or by moving to the Mihomo kernel.

Change 4. DSCP-based routing: one program — one route

The most unusual feature of the release. The router can see packets but not which app generated them. DSCP markings solve this on the client side:

DSCP 63 — force traffic into the normal XKeen chain (i.e., into the proxy), even if the ports wouldn’t normally route there;
DSCP 62 — exclude from proxying.

On Windows, the mark is set via QoS policy: gpedit.msc → “QoS based on policy” → create a policy, specify the executable, DSCP mark, and optionally addresses, protocol and ports. Before that you need a registry tweak:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\QoS]
"Do not use NLA"="1"

After creating the policy, just restart the application; a system reboot is not required.

Note:

Limitations: gpedit.msc is only in the full editions of Windows. Home users will have to edit the registry manually. And yes, this works specifically for Windows — a TV or Android box doesn’t have this lever.

Change 5. Mixed became Hybrid, and port 443 is not needed for everyone

The mode formerly called Mixed is now called Hybrid. If you copy configs or year-old instructions, keep that in mind.

More importantly: the second point: exposing port 443 is now required only for TProxy mode. Previously the step of moving Keenetic’s web configurator from 443 to 8443/5443 was mandatory for everyone. Now with Hybrid you can skip it.

What else changed in minor details

Port files were reduced to two: port_proxying.lst (what to proxy) and port_exclude.lst (what not to proxy). They do not work simultaneously — if both are filled, the proxying list has priority.
Gate to its own GitHub proxy via gh_proxy in /opt/etc/xkeen/xkeen.json — relevant when GitHub on the router won’t respond.
Re-try downloads: retries_download (default 1) and retry_delay_download (2 seconds). Useful to increase if the installer fails mid-way.
File descriptor limits moved to config: arm64_fd (default 40000) and other_fd (10000).
AdGuard Home finally shows the IP of the specific client, not the router — with the command xkeen -aghfix on (for 2.0+) or the config option "routeOnly": true in the Xray config.
The Entware traffic is proxied as well.

Quick reference: commands you actually need

Command	What it does
`xkeen -start` / `-stop`	Start and stop proxying
`xkeen -status`	Current status
`xkeen -ux`	Switch the Xray core version, including rollback
`xkeen -dns`	Proxy DNS
`xkeen -aghfix on`	Fix client detection in AdGuard Home
`xkeen -fd`	Enable file descriptor control
`xkeen -d <seconds>`	Delay start after router boot
`xkeen -diag`	Collect diagnostic report
`xkeen -io`	Offline installation (archive and binaries pre-staged in `/opt/sbin/`)
`xkeen -h`	Full current list — the only reliable source

If you’re setting it up from scratch (Entware must be present):

opkg update && opkg install curl tar && cd /tmp
sh -c "$(curl -sSL https://raw.githubusercontent.com/jameszeroX/XKeen/main/install.sh)"

The installer will guide you through nine steps: XKeen version → selection of proxying cores → their versions → GeoSite databases → GeoIP databases → whether to exclude Russian subnets → auto-update of geo-files and its schedule → auto-start on router boot.

Configs after installation are located at /opt/etc/xray/configs/ (or /opt/etc/mihomo/): 03_inbounds.json — listening mode, 04_outbounds.json — your server data, 05_routing.json — routing rules.

Hardware: what it will run on, and what it will struggle with

Architecture	Models (partially)	Reality
aarch64 — take this	Peak KN-2710, Ultra/Titan KN-1811/1812, Giga KN-1012, Hopper KN-3811/3812/2312, Hero 5G KN-4110	Normal speeds, recommended option
mipsel	Giga/Hero KN-1010/1011, Ultra KN-1810, Viva/Skipper KN-1910/1912/1913, Giant KN-2610, Hero 4G KN-2310/2311, Hopper KN-3810	Will boot, but won’t give high internet speeds
mips	Ultra SE/Peak DSL KN-2510, Giga SE/Hero DSL KN-2410, DSL/Omni KN-2010, Hopper DSL KN-3610	Budget option, some models at 580 MHz

Error:

Separately named KN-3810 and KN-3610 on EcoNet processors: they physically can’t run Xray. If you have one of these — the only thing that helps is to limit proxying to ports 80/443 and trim the geosite/geoip sets. Expecting gigabit speeds is pointless. Another concrete pitfall: on the architecture mipsle do not use Xray core 26.3.27.

Web panel: XKeen-UI

If you don’t want to tinker with SSH, there’s a third-party project XKeen-UI — a panel in TypeScript and Rust that provides config editing with validation, log viewing with filtering, switching and updating Xray/Mihomo cores, generating outbound links, and working with Clash API for Mihomo.

curl https://raw.githubusercontent.com/zxc-rv/XKeen-UI/main/setup.sh | sh

The panel runs on port 1000, the port is changed in /opt/etc/init.d/S99xkeen-ui. Management — with the same script: start, restart, stop, status.

Security:

The panel authors warn: opening access to it from the Internet without additional protection is a direct path to compromising the router. Keep it only in the local network, and if you need external access — wrap it in a VPN rather than port-forwarding. A reminder why this is not paranoia: in November 2025 Keenetic forcibly updated devices on KeeneticOS below 4.3 precisely because automatic password scanners were breaking routers with an exposed web configurator and weak passwords.

What XKeen will not do

An honest list of limitations — it’s present right in the project FAQ, and that’s a good sign.

Ping and tracert through a proxy won’t work. ICMP lives at the network layer, proxies operate at the application layer. This isn’t a bug, it’s device incompatibility. You won’t be able to diagnose connectivity with usual tools over a tunnel.

Advertisements on YouTube aren’t cut by routing or DNS — they come from the same addresses as the video. Only SmartTube and similar clients or a subscription help.

WebRTC and QUIC leaks remain possible — a real IP can leak outside the tunnel. Fixed by disabling WebRTC in the browser or blocking UDP/443.

Router is a bottleneck. Transparent proxying is entirely dependent on the router’s CPU. The difference between aarch64 and mips here isn’t “slightly slower,” but orders of magnitude.

And a general note: XKeen solves the routing problem but not the reliability of the transport itself. If your VLESS/Reality throttles DPI — router rules won’t help; the problem lies lower in the stack. There are separate discussions about blocking by symptoms and how Reality works (linked).

Sources

Question:

Who has already migrated to 2.0 — what broke during the update, and did you have to reconfigure policies? And separately interested in DSCP: is anyone actually using it in practice, or is it easier to run applications on separate devices?