WireGuard outbound problem in tun_linux

[Kapkap5454]

Integrity requirements

• I have read all the comments in the issue template and ensured that this issue meet the requirements.
• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I provided the complete config and logs, rather than just providing the truncated parts based on my own judgment.
• I searched issues and did not find any similar issues.
• The problem can be successfully reproduced in the latest Release

Description

Xray 26.3.23 + v2rayN 7.19.5 TUN + Windows 10. XHTTP + Reality.
After updating:

1. I have persistent connection to one of the servers using mosh console (uses UDP). It can't connect after update. It doesn't connect even when starting new connection.
2. https://quic.nginx.org/ test shows no QUIC connection in browser after update. Before update it worked.

I can't confirm it breaks all UDP, but at least some.
Wireshark shows outgoing packets for the server i am trying to reach via mosh, but no incoming.

Happens only if both client and server are updated. Problem doesn't appear when server xray remains old and client is updated (probably also would work vice-versa? didn't test that).

*weird, client logs show it even accepted something from target address?

I truncated client log a little, as v2rayN on latest versions started to produce many error messages, connected with new tun protect mode. But i tested and have this bug even on older v2rayN 7.18.0.

Reproduction Method

1. Update Xray.
2. Try using mosh to connect to server or try https://quic.nginx.org/. No connection and no QUIC.

Client config

Details

{
  "log": {
    "loglevel": "debug"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 49371,
      "protocol": "shadowsocks",
      "settings": {
        "network": "tcp,udp",
        "method": "none",
        "password": "none"
      },
      "tag": "proxy-relay-ss"
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "11.11.111.11",
            "port": 443,
            "users": [
              {
                "id": "d62",
                "email": "t@t.tt",
                "security": "auto",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "reality",
        "xhttpSettings": {
          "path": "/lalala",
          "mode": "stream-one"
        },
        "realitySettings": {
          "serverName": "www.somesite.com",
          "fingerprint": "chrome",
          "show": false,
          "publicKey": "ZY",
          "shortId": "",
          "spiderX": "",
          "mldsa65Verify": ""
        },
        "sockopt": {
          "dialerProxy": "tun-protect-ss"
        }
      },
      "mux": {
        "enabled": false,
        "concurrency": -1
      }
    },
    {
      "tag": "tun-protect-ss",
      "protocol": "shadowsocks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "method": "none",
            "ota": false,
            "password": "none",
            "port": 49368,
            "level": 1
          }
        ]
      },
      "streamSettings": {
        "network": "tcp"
      },
      "mux": {
        "enabled": false,
        "concurrency": -1
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "api"
        ],
        "outboundTag": "api"
      },
      {
        "type": "field",
        "inboundTag": [
          "proxy-relay-ss"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

Server config

Details

{
  "log": {
    "loglevel": "debug",
    "access": "/var/log/xray/access.log",
    "error": "/var/log/xray/error.log"
  },
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "tag": "reality-in",
      "settings": {
        "clients": [
          {
            "id": "d62",
            "email": "user1",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none",
        "fallbacks": [
          {
            "dest": "@xhttp",
            "xver": 1
          }
        ]
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "target": "www.somesite.com:443",
          "xver": 0,
          "serverNames": [
            "www.somesite.com",
          ],
          "privateKey": "INA",
          "minClientVer": "",
          "maxClientVer": "",
          "maxTimeDiff": 0,
          "shortIds": [""]
        }
      }
    },
    {
      "listen": "@xhttp",
      "protocol": "vless",
      "tag": "reality-in-xhttp",
      "settings": {
        "clients": [
          {
            "id": "d62",
            "email": "user1"
          }        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "sockopt": {
          "acceptProxyProtocol": true
        },
        "xhttpSettings": {
          "path": "/lalala"
        }
      }
    },
  "outbounds": [
    {
     "protocol": "freedom",
     "tag": "direct"
    },
  ]
}

Client log

Details

2026/03/26 13:08:28.949481 [Info] [2906361306] transport/internet/splithttp: XHTTP is dialing to tcp:11.11.111.11:443, mode stream-one, HTTP version 2, host www.somesite.com
2026/03/26 13:08:28.949512 [Info] [2906361306] proxy/vless/outbound: tunneling request to udp:99.99.999.999:60001 via 11.11.111.11:443
2026/03/26 13:08:31.956522 [Info] [2906361306] proxy/shadowsocks: tunnelling request to udp:99.99.999.999:60001
2026/03/26 13:08:31.956522 [Debug] [2906361306] transport/internet/udp: dispatch request to: udp:99.99.999.999:60001
2026/03/26 13:08:31.956522 [Info] [2906361306] transport/internet/udp: establishing new connection for udp:99.99.999.999:60001
2026/03/26 13:08:31.956522 [Info] [2906361306] app/dispatcher: taking detour [proxy] for [udp:99.99.999.999:60001]
2026/03/26 13:08:31.956522 from udp:127.0.0.1:63615 accepted udp:99.99.999.999:60001 [proxy-relay-ss -> proxy]
2026/03/26 13:08:34.966868 [Info] [1789288886] app/dispatcher: taking detour [proxy] for [udp:99.99.999.999:60001]
2026/03/26 13:08:55.280919 [Info] [2584618876] app/proxyman/inbound: connection ends > proxy/shadowsocks: connection ends > context canceled

Server log

Details

2026/03/26 11:30:23.534565 [Info] [2726084989] proxy/vless/inbound: received request for tcp:v1.mux.cool:0
2026/03/26 11:30:23.534572 [Info] [2726084989] common/mux: received request for udp:99.99.999.999:60001
2026/03/26 11:30:23.534599 [Info] [2726084989] common/mux: XUDP new [8 113 212 83 181 7 103 79]
2026/03/26 11:30:23.534603 [Info] [2726084989] app/dispatcher: default route for udp:99.99.999.999:60001
2026/03/26 11:30:23.534607 [Info] [2726084989] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/wireguard: connection ends > write udp 172.16.0.2:58553->99.99.999.999:60001: use of WriteTo with pre-connected connection
2026/03/26 11:30:23.534612 [Info] [2726084989] common/mux: session 0 ends. > io: read/write on closed pipe
2026/03/26 11:30:23.534616 [Debug] common/mux: XUDP put [8 113 212 83 181 7 103 79]
2026/03/26 11:30:23.559866 [Info] [2726084989] common/mux: unexpected EOF > common/mux: failed to read metadata > stream error: stream ID 139; CANCEL
2026/03/26 11:30:23.992583 [Info] [4104545062] proxy/vless/inbound: firstLen = 54

[RPRX]

VLESS 和 XUDP 代理 UDP 的相关代码就没动且它们是 UoT，@LjhAUMEM 是不是底层传输 UDP 那里改出了问题

[deadnews]

wireguard inbound is broken too on 26.3.23.

[LjhAUMEM]

这也没有应用上 fm 啊，其他传输层呢，毕竟 xhttp 也大改过，我试试能不能复现吧

[RPRX]

比如 Freedom UDP 那里会不会因为兼容了 fm 而出现了小问题

[Fangliding]

版本更新后的问题最好还是找出问题的commit最快

[RPRX]

Problem doesn't appear when server xray remains old and client is updated

@LjhAUMEM 如果有问题的话应该不是客户端侧的问题，而是 Freedom UDP

[LjhAUMEM]

这还是不是个 socks 就能复现的场景...

我先解决下 tun 环境测试下吧

[LjhAUMEM]

@Kapkap5454 Can you reproduce this using this configuration? Because my Mosh connection is successful.

{
  "log": { "loglevel": "debug" },
  "inbounds": [
    {
      "protocol": "tun"
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "address": "", // 1
        "port": 1081,
        "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
        "encryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "reality",
        "realitySettings": {
          "fingerprint": "chrome",
          "password": "QrYbmYVHEC1DY16VY6OYav_SIM5riA-BqfiTB_vsAiE"
        },
        "sockopt": {
          "interface": "" // 2
        }
      }
    }
  ]
}

{
  "log": { "loglevel": "debug" },
  "inbounds": [
    {
      // "listen": "127.0.0.1",
      "port": 1081,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "5783a3e7-e373-51cd-8642-c83782b807c5"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "reality",
        "realitySettings": {
          "target": "www.microsoft.com:443",
          "serverNames": [""],
          "privateKey": "qPpjnk17hSEDIKcLumTghCcyzTqyDqlSsUJQfrR6WkE",
          "shortIds": [""]
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    }
  ]
}

This route is just an example; you need to replace it with your gateway and Xray Tun ID. see readme

route add 192.168.2.1 mask 255.255.255.255 192.168.2.1 metric 1
route add 0.0.0.0 mask 0.0.0.0 0.0.0.0 if 30 metric 5

route delete 0.0.0.0 if 30
route delete 192.168.2.1

And quic.nginx.org is working normally on my end.

[LjhAUMEM]

Problem doesn't appear when server xray remains old and client is updated

@LjhAUMEM 如果有问题的话应该不是客户端侧的问题，而是 Freedom UDP

freedom 我改的那里如果不启用 fm 行为和之前理应没区别

他这个配置客户端最终出站是本地 ss，服务端入站却是 xhttp，嗯...

简单搭了一个 xhttp 无法复现，等他回复吧

[RPRX]

它那个 tun 不是 Xray 的，而且按他说仅升级客户端的话没问题

他这个配置客户端最终出站是本地 ss，服务端入站却是 xhttp，嗯...

客户端是 SS 入、XHTTP 出，难道是中转

freedom 我改的那里如果不启用 fm 行为和之前理应没区别

那就先关了看有没有其他人能复现吧，最近这些 issues 都奇奇怪怪的

[Kapkap5454]

Thank you guys for your attention. Although I have to admit translation from Chinese sometimes gives confusing sentences.

The problem was WARP outbound using wireguard. I omitted it from my server config, as notes advised to delete all parts of config that weren't relevant, I didn't expect this to be relevant.
{
"protocol": "wireguard",
"tag": "warp",
"settings": {
"secretKey": "Warp_Private_Key",
"address": [
"Warp_IP4_Address/32",
"Warp_IP6_Address/128"
],
"peers": [
{
"endpoint": "Warp_Endpoint",
"publicKey": "Warp_Public_Key"
}
],
"mtu": 1280,
"reserved": "Warp_Client_ID",
"workers": 2,
"domainStrategy": "ForceIP"
}
}

So far the problem only occurs when newest xray is on the server. Client xray version doesn't matter. As I understand you are already aware of some wireguard problems.

@RPRX 客户端是 SS 入、XHTTP 出，难道是中转
This is how it is done now in newest v2rayN, they made some tun protect mode that utlizes shadowsocks to protect against loopback calls. Unfortunately that breaks some things like ssh on windows in tun mode. They are waiting for
pr #5594 to finish before switching to xray tun, right now v2rayN uses singbox tun + xray for the connection itself.

[Fangliding]

依旧不看说明乱填模板

[Kapkap5454]

依旧不看说明乱填模板

Sorry Fangliding, I didn't have much choice. I read the instruction carefully. The instruction says:

1. Please provide the configuration files that can reproduce the problem, including the server and client.
2. Don't just paste a big exported config file here. Eliminate useless inbound/outbound, rules, options, this can help determine the problem, if you really want to get help.

I gave it a thought about testing config without warp. But I couldn't do it on the actual server, it could possibly make some background leak to a local country app, which would leak the server IP to GFW, resulting in possible block.
I also tried to make an exact copy of the actual server on the same hosting, for testing. But because the hosting itself is in "suspicious list" for GFW, it blocks almost all connections, it's a miracle the actual server works. So copies I made, I couldn't connect to them successfully to test.

Then I decided its highly unlikely to be the problem, its just simple warp. So I had to follow 2).

[RPRX]

若该问题存在，等今天发了正式版引来更多人测试后等别人更准确地报告该问题吧