Very high latency with VLESS+XHTTP+REALITY

[Lopolin-LP]

So I'm trying to setup a personal VPN server for a friend in Russia (I am outside of Russia). So far everything has went well with Xray-core, however the Latency seems really bad? At least in practise.

I am doing these tests on my own Network. This has about 8 MByte/s Download speed with I think about 2 MByte/s up. The TCPing to my server is about 15 ms, while the "Real Delay" in v2RayNG is 20 ms. Seems fine so far. Trying to load YouTube in Firefox though takes 7 seconds (when all resources are cached already). Usually it's 0.5 seconds. BBR is enabled.

This delay already took place even with network set to raw/tcp and security being none (decryption was set from the beginning though)

Any Idea what is going on here? I am unsure about both the server and client configuration.

Here's the server configuration, it's just the default but a bit more adapted:

// REFERENCE:
// https://github.com/XTLS/Xray-examples
// https://xtls.github.io/config/
// Common config files, whether server or client, have 5 parts. Plus newbie interpretation:
// ┌─ 1*log Log Settings - What to write, where to write (evidence available when errors occur)
// ├─ 2_dns DNS Settings - How to query DNS (prevent DNS pollution, prevent snooping, avoid matching domestic sites to foreign servers, etc.)
// ├─ 3_routing Routing Settings - How to classify and process traffic (whether to filter ads, split domestic/international traffic)
// ├─ 4_inbounds Inbound Settings - What traffic can flow into Xray
// └─ 5_outbounds Outbound Settings - Where the traffic flowing out of Xray goes
{
  // 1_Log Settings
  "log": {
    "loglevel": "warning" // Content from least to most: "none", "error", "warning", "info", "debug"
  },
  // 2_DNS Settings
  "dns": {
    "servers": [
      "https+local://1.1.1.1/dns-query", // Prefer 1.1.1.1 DoH query, sacrifices speed but prevents ISP snooping
      "localhost"
    ]
  },
  // 3_Routing Settings
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      // 3.1 Prevent local server loop issues: e.g., intranet attacks or abuse, wrong local loops, etc.
      {
        "ip": [
          "geoip:private" // Routing condition: rules named "private" in the geoip file (local)
        ],
        "outboundTag": "block" // Routing strategy: hand over to outbound "block" processing (blackhole blocking)
      },
      // {
      //   // 3.2 Prevent server from directly connecting to domestic (CN) IPs
      //   "ip": ["geoip:ru"],
      //   "outboundTag": "block"
      // },
      // 3.3 Block Ads
      {
        "domain": [
          "geosite:category-ads-all" // Routing condition: rules named "category-ads-all" in the geosite file (various ad domains)
        ],
        "outboundTag": "block" // Routing strategy: hand over to outbound "block" processing (blackhole blocking)
      }
    ]
  },
  // 4_Inbound Settings
  // 4.1 Here only one simplest vless+xtls inbound is written, because this is Xray's most powerful mode. If needed, please add others based on templates.
  "inbounds": [
    {
      "port": 25565,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "****", // Fill in your UUID
            "flow": "xtls-rprx-vision",
            "level": 0,
            "email": "vpsadmin@yourdomain.com"
          }
        ],
        "decryption": "****"
        // "fallbacks": [
        //   {
        //     "dest": 80 // Default fallback to the probe-resistant proxy
        //   }
        // ]
      },
      "streamSettings": {
        "network": "xhttp",
        "xhttpSettings": {
          "path": "/search"
        },
        "security": "reality",
        "realitySettings": {
          "dest": "yandex.com:443", // A website that support TLS1.3 and h2. You can also use `1.1.1.1:443` as dest
          "serverNames": [
            "yandex.com",    // A server name in the cert of dest site. If you use `1.1.1.1:443` as dest, then you can leave `serverNames` empty, it is a possible ways to bypass Iran's internet speed restrictions.
            "mail.yandex.com",
            "yandex.ru"
          ],
          "privateKey": "****", // run `xray x25519` to generate. Public and private keys need to be corresponding.
          "shortIds": [// Required, list of shortIds available to clients, can be used to distinguish different clients
            "", // If this item exists, client shortId can be empty
            "****"
          ]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"],
        "routeOnly": true
      }
    }
  ],
  // 5_Outbound Settings
  "outbounds": [
    // 5.1 The first outbound is the default rule, freedom is direct connection (VPS is already on the external network, so direct connection)
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    // 5.2 Blocking rule, blackhole protocol sends traffic into a black hole (blocking)
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

[wy15]

不用上下行分离，上行cdn，下行直连，network使用raw比较好。可以试试

[Lopolin-LP]

I'm sorry but I don't quite understand what you mean (⌒_⌒;) . I'm having a really bad time finding much information's about this whole method with a CDN. If I understand this in the context of a Content-Delivery-Network, that would mean running it on a server somewhere where such a delivery service is also running. But I am currently running Xray on a Computer in my house, not on a VPS (which I know is not a great idea, but this is just a test for now).

The problem I'm facing is that connecting to Xray through the public IP of my house adds somehow 200ms of latency than if I do so through the Local Network (LAN). I think that this might be because the latency just exponentially increases due to how many and how often packets are sent to get a request through? I'm not sure.

But even if I can't fix that, what do you mean with "separating upload/uplink and download/downlink" and "use a direct downlink connection"? I'd love to try, but I don't quite understand how it would practically work.

[Lopolin-LP]

After arguing with Claude for two days I finally pinned down the issue! In short: It's DNS.

In long: Go's Network Stack (Dialer? and DNS resolver) are extremely slow on my system for some odd reason. Maybe it just doesn't play nice with systemd-resolved and NetworkManager; who knows, because I don't. Forcing Xray to use its own networking stack fixes this.

The changes needed are as follows:

{
    "dns": {
        "servers": [
            "https+local://1.1.1.1/dns-query" // Configure at least one server
            // DO NOT set localhost as a server, since that uses Go's DNS Resolver / Network Stack.
        ]
    },
    "outbounds": [
        {
            "tag": "direct",
            "protocol": "freedom",
            "settings": {
                "domainStrategy": "UseIP" // Uses Xray's Dial instead of Go's to make connections.
            }
        }
    ]
}

The Symptoms for this were that whenever a DNS request was sent through Xray the request took ~2.2 seconds to complete.

EDIT: Turns out Go exclusively uses /etc/resolv.conf, which I hadn't configured properly before. Fixing that with a symlink made it all work without these tweaks!

[kfr2359]

Hi,
Could you share how exactly you've configured /etc/resolv.conf? I have the similar kind of latency on every vless server I've setup and thought it's just a "feature" of the protocol. The conf is present and set to 127.0.0.53, thought that relying on systemd was okay.

[Lopolin-LP]

Hi, Could you share how exactly you've configured /etc/resolv.conf?

@kfr2359 From what it seems I have configured it like you have, but just to double check: In short I followed the arch wiki. Which meant running the following on the xray server:

sudo mv /etc/resolv.conf /etc/resolv.conf.backup # just in case
sudo ln -sf ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart NetworkManager.service

Then just restarting Xray (so it reloads /etc/resolv.conf), and then it was fixed.

If you were asking for what is in the file, it's just that IP at the top and Netbird's DNS.

Well, considering that you have the IP 127.0.0.53 in that file, I assume it's already successfully linked to /run/systemd/resolve/stub-resolv.conf, which you can check like this:

realpath /etc/resolv.conf
# this should print /run/systemd/resolve/stub-resolv.conf

If that's all done, and there's still a delay, then check if it's related to GoLang's network stack or something else.

I would first try the following:

• modify your config as I had shown above (adding the domainStrategy to freedom and specifying a DNS server in the config) and check if it fixes the delay.
• check the output of resolvectl status. I would recommend you make sure that under "Global settings" you have your preferred DNS servers. Here the arch wiki explains how to do that once more.
• Run this "awesome" command below that definitely not an AI hallucinated to me, which shows when what completed. It simply pings a site of google that all android phones ping, however since it's a domain, it requires DNS so it's perfect for this.

curl -o /dev/null -w "namelookup: %{time_namelookup}s\nconnect: %{time_connect}s\nappconnect: %{time_appconnect}s\npretransfer: %{time_pretransfer}s\nstarttransfer: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://www.gstatic.com/generate_204

I can't help more than that since I don't have access to your computer, but I hope this helps!