Xray-core 2026: Why Your WARP Doesn't Feed Gemini and Why RPRX Bans "Naked" VLESS

1. Ban on unencrypted traffic

RPRX (the developer of Xray) has issued a strict ultimatum: in 2026, raw traffic through VPN protocols on public ports will be prohibited.

Many in Iran and Russia have started using VLESS without TLS (on port 80 or through CDN) because TSPU is sometimes more lenient towards plain HTTP than suspicious TLS.

Now mandatory VLESS Encryption is being introduced. If you use a transport like xHTTP without REALITY/TLS, you must enable encryption within the protocol itself. Otherwise, the core will simply refuse to raise inbound connections.

How this will work:

By default, such connections will be locked inside Localhost. That is, if you raised VLESS on port 80 without encryption, it simply will not accept packets from outside.

What to do:

• Developers insist on switching to VLESS Encryption. They confirm in chats that this solution has already been tested and works reliably.

• For those who are set in their ways and want to keep everything as it is, a special loophole will be provided with a special environment variable (RPRX did not provide an example of what the variable is, or I didn't search well), which will allow forcibly allowing unencrypted connections. However, this will be considered an unsafe mode.

2. A trap for Gemini: Why does WARP on the node "not work"?

"I set up WARP on a European node, added rules for Gemini/AI Studio, and Google still says 'Not available in your region'" sound familiar?)

Anatomy of the error:
In 90% of cases, this is a logic bug in the routing block. Rules in Xray are applied top down. If you have a direct rule for geosite:google higher up the list, the request to Gemini will go directly through the hoster's IP (which is often banned by Google), without reaching the rule with the warp tag.

Correct order in the config:

"routing": {
  "rules": [
    {
      "type": "field",
      "outboundTag": "warp-out", // First, we wrap the neural networks in WARP
      "domain": [
        "aistudio.google.com",
        "gemini.google.com"
      ]
    },
    {
      "type": "field",
      "outboundTag": "DIRECT", // And only then everything else Russian/service-related
      "domain": [
        "geosite:google", 
        "geosite:category-ru"
      ]
    }
  ]
}

If WARP is still crashing, check IPv6. The official WARP client on SOCKS ports (like 40000) often does not handle UDP. If Gemini tries to communicate over QUIC, everything will crash. Fix: forcibly set domainStrategy: UseIPv4 in the outbound of WARP

3. Import bug: v2raytun:// and "invalid URL"

If you distribute subscriptions through Marzban or your own scripts, you may have encountered that links like v2raytun://import/{link} give an error for 30% of users

What's the deal: If your panel is not on the standard port 443 (for example, on 8000), client applications often incorrectly parse the prefixes
In your panel's .env file, be sure to specify the prefix with an explicit port:
XRAY_SUBSCRIPTION_URL_PREFIX = "https://your-domain.com:8000"
Without this, one-click import turns into a lottery.

4. Hysteria2: Now officially inside Xray?

On GitHub, they are actively developing native Hysteria2 inbound. Previously, it was necessary to create chains with a separate binary, now it will be part of the core.

What does this provide?

1. UDP Hop: It's now harder to ban Hysteria by signature "stable stream on one UDP port". Ports will jump

2. Brutal Congestion: An aggressive method to combat packet loss. If the provider shapes the channel, Hysteria will break through it by means of repeats
   
   Draft config (for reference):

"streamSettings": {
    "network": "hysteria",
    "hysteriaSettings": {
        "version": 2,
        "congestion": "brutal",
        "up": "100mbps",
        "down": "100mbps",
        "udphop": { "port": "20000-50000", "interval": 30 }
    }
}

5. Counting Bytes

Another cool feature that the community is requesting is the addition of request/response size in access.log
Why do we need this? Currently, the logs only show the fact of the connection. If you have a neighbor who is using your config to download terabytes of torrents, you will only find out about it from the bill from the host. In new versions, they promise to include request_bytes and response_bytes directly in the log line. This will allow you to configure Fail2Ban for those who consume too much within a single session.

Guys, I am planning to open a TG channel or create a chat to share a lot of useful information there, as articles tend to disappear with a 403 error. What do you think, is this something anyone needs?