v26.6.22 XHTTP + Unix Domain Socket: trustedXForwardedFor with 0.0.0.0/0 does not match UDS connections, causing "ignored potentially forged X-Forwarded-For"

[anartikov]

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-core version: v26.6.22 (includes PR #6309 – trustedXForwardedFor enforcement)

When an XHTTP inbound listens on a Unix Domain Socket (e.g., /dev/shm/test.sock) and sockopt.trustedXForwardedFor is set to ["0.0.0.0/0"], Xray-core still rejects the X-Forwarded-For header with:

ERROR - XRAY: common/protocol/http: ignored potentially forged "X-Forwarded-For" from 0.0.0.0:0:

The problem is that for UDS connections the remote address is always 0.0.0.0:0. Even though 0.0.0.0/0 should match any IPv4 address, the check fails – likely because the zero address is treated specially or not matched against CIDR rules. As a result, it is impossible to make Xray trust X-Forwarded-For headers forwarded by a local reverse proxy (nginx) when using UDS, unless trustedXForwardedFor is left empty (which then triggers a warning but no error). However, the warning also spams logs.

Additionally, after restarting Xray, the log occasionally shows:
ERROR - XRAY: transport/internet/splithttp: failed to serve HTTP for XHTTP > accept unix /dev/shm/test.sock: use of closed network connection
This may be a separate UDS lifecycle issue.

Expected behavior:

• 0.0.0.0/0 in trustedXForwardedFor should match any remote address, including 0.0.0.0:0 from UDS, allowing the header to be trusted.
• Or provide a clear way to trust UDS connections (e.g., a special keyword "unix").

Reproduction Method

1. Set up an Xray server with an XHTTP inbound listening on a Unix socket, and configure sockopt.trustedXForwardedFor as ["0.0.0.0/0"].
2. Configure nginx (or any reverse proxy) to forward requests to the socket, adding an X-Forwarded-For header with the client's real IP.
3. Connect using any VLESS + XHTTP client (mode packet-up).
4. Check server logs – the error appears for every request.

If trustedXForwardedFor is left empty, the error disappears, but a warning is logged instead (which is the intended behavior, but not helpful for UDS).

Client config

Details

 { "outbounds": [ { "protocol": "vless", "settings": { "vnext": [ { "address": "192.0.2.100", "port": 443, "users": [ { "id": "e814f1e0-0000-4000-a000-000000000000", "encryption": "none" } ] } ] }, "streamSettings": { "network": "xhttp", "security": "tls", "tlsSettings": { "serverName": "test.example.com", "fingerprint": "firefox" }, "xhttpSettings": { "path": "/testpath", "host": "test.example.com", "mode": "packet-up" } } } ] } 

Server config

Details

 { "inbounds": [ { "listen": "/dev/shm/test.sock,0666", "port": 0, "protocol": "vless", "settings": { "clients": [ { "id": "e814f1e0-0000-4000-a000-000000000000" } ], "decryption": "none" }, "streamSettings": { "network": "xhttp", "security": "none", "xhttpSettings": { "path": "/testpath", "mode": "packet-up" }, "sockopt": { "trustedXForwardedFor": ["0.0.0.0/0"] } } } ] } 

Client log

(debug log not needed; the issue is on server side)

Server log

Details

 2026/06/23 20:34:43 ERROR - XRAY: common/protocol/http: ignored potentially forged "X-Forwarded-For" from 0.0.0.0:0: 203.0.113.45 2026/06/23 20:34:43 [Info] [123456789] proxy/vless/inbound: firstLen = 70 ... 2026/06/23 20:34:44 ERROR - XRAY: transport/internet/splithttp: failed to serve HTTP for XHTTP > accept unix /dev/shm/test.sock: use of closed network connection 

[Fangliding]

这个参数的含义不像nginx是指定可信任的源IP 它是过滤请求中有没有含有数组中的请求头（任意一个）
如果你想无条件信任使用 ["X-Forwarded-For"] 即可