v13: xhttp nodes broken server-side — fail with every client including official Hiddify desktop/CLI #5570
Description
Activity
I hit the same problem on 13.0.3 with the Hiddify app 4.1.1 (Linux and Android). I tracked it down, and it's in the client config the panel generates, not on the server.
The server side works. I ran all 18 xhttp configs from the
xraysubscription through Xray 26.3.27 as a client, and every one connected. I then ran the 4.1.1 singbox subscription through the official hiddify-core v4.1.0 release (hiddify-core build+srun, same as the app) and reproducedconnection download handshake: read payload: io: read/write on closed pipeon all 9 xhttp configs. ws/httpupgrade/tuic/hysteria2 worked.There are two bugs in
hiddifypanel/proxy_v3/proxy_templates/hiddify-core/client/:1.
streams/xhttp.j2: the download leg uses the domain instead of the IP.
The main outbound gets"server": "<IP>", butdownloadSettingsgets"server": "{{ domain.download.server() }}", which renders the domain name. The download dialer inside the xhttp transport has no domain resolver, so the download handshake fails. Changing the server to the IP fixes all the TLS H1/H2 configs.
(Adding"domain_resolver"todownloadSettingsworks on core 4.0.4, but core 4.1.0 rejects it as anunknown field, so it's not an option.)- "server": "{{ domain.download.server() }}", + "server": "{{ domain.download.server(True) }}",
2.
tls/tls_http.j2: uTLS is enabled on h3 (QUIC) legs.
Every leg gets"utls": {"enabled": true, "fingerprint": "chrome"}, including ones with"alpn": ["h3"]. uTLS doesn't support QUIC, so every config with a QUIC upload or download leg fails, even after fix 1.- {% if fp and fp!="none" %} + {% if fp and fp!="none" and "h3" not in tls_layer.alpns() %}
Result: with both changes and a panel restart (
systemctl restart hiddify-panel), all 9 xhttp configs in the 4.1.1 subscription pass on hiddify-core v4.1.0 and v4.0.4: TLS H1, TLS H2, QUIC, and all 6 configs with different upload/download legs. The other protocols are unchanged. Clients need to refresh the subscription afterwards.Files are under
/opt/hiddify-manager/.venv313/lib/python3.13/site-packages/hiddifypanel/proxy_v3/proxy_templates/hiddify-core/client/and will be overwritten by the next panel update. I checked HiddifyPanelmainanddev, and neither has a fix yet.Side note: the panel also sends a malformed header value,
"sec-ch-ua-platform": "['Android'". It doesn't affect connectivity, but it's probably a quoting bug indefault_headers.Submitted the two template fixes from my comment above (plus a fix for the malformed
sec-ch-ua-platformheader) as a PR: hiddify/hiddifypanel#45
Environment
Symptom
All 18 xhttp nodes (every up/down combo, HC and non-HC) fail while ws / grpc / httpupgrade / trojan / naive / hysteria2 / tuic nodes on the same server work fine.
Client-side error (both Karing and official Hiddify):
During an earlier apply window the server xray logged:
Chain appears to be: rpxy-l4 (:443) → haproxy (127.0.0.1:901, in-httpmode-ssl, path map →
backend http_*mode httpsend-proxy-v2 proto h1) → xray inbound (e.g. 127.0.0.1:49952, xhttp, acceptProxyProtocol=true).Notes
"loglevel": "CRITICAL"so rejections are invisible in normal operation — worth logging handshake failures at Warning.Thanks!