Files
3x-ui/sub
MHSanaei 8046d1519d fix(links): include TCP HTTP host header in share links
The inbound form intentionally only exposes the response side of the
TCP HTTP header object (xray-core's inbound listener reads the
response object, not request — see the existing comment in
InboundFormModal). But the share-link generators were still reading
the Host header from request.headers, so the configured value ended
up in tcpSettings.header.response.headers while the link query
emitted host= (empty).

Fix the host lookup in both code paths:
- sub/subService.go: applyShareNetworkParams (VLESS / Trojan /
  Shadowsocks share URLs) and applyVmessNetworkParams (the VMess
  base64 JSON link) now try header.response.headers first and fall
  back to request.headers for legacy / hand-edited configs.
- frontend/src/lib/xray/inbound-link.ts mirrors the same fallback in
  the three TCP HTTP branches (VMess obj, VLESS params, the shared
  Trojan+Shadowsocks writer) so the JS-side generator used by the
  API docs preview stays in sync with the Go output.

Also restore the request-side inputs (version / method / path /
headers) under the TCP HTTP toggle in InboundFormModal. They were
previously removed because xray-core ignores them on the inbound
side, but they're still useful when copying the same config out to
an outbound or hand-tuning the share link, and they no longer
mislead users about Host — the link now derives Host from
response.headers.host where the response-only form writes it.
2026-05-28 13:54:04 +02:00
..