Hysteria v2 inbound starts successfully, receives client UDP packets, but sends no response packets and client always times out

[shadow-enthusiast]

Integrity requirements

• I have read all the comments in the issue template and ensured that this issue meets the requirements.
• I confirm that I have read the documentation, understand the meaning of all configuration items used below, and did not pile up random or unnecessary options.
• I provide the full minimal config shape, startup log, certificate generation details, and packet capture behavior, not only selectively truncated fragments.
• I searched existing issues and did not find an exact duplicate for this case.
• The problem is reproducible on the latest Release I tested.

Description

I am testing Hysteria v2 inbound on Xray Core 26.3.27.

The inbound starts successfully, binds to the configured UDP port, and client UDP packets clearly reach the server host. However, during connection attempts, the server appears to send no UDP response packets at all, and the client always ends with timeout.

Observed behavior:

1. Xray starts successfully
2. UDP packets from the client reach the server
3. Xray does not appear to send any UDP packets back to the client
4. client times out
5. server logs contain startup information only, but no useful per-connection Hysteria/QUIC error

This does not look like a basic firewall/routing problem, because incoming UDP packets are visible on the server interface.

It also does not look like a startup/config parse failure, because Xray starts normally and binds successfully.

In earlier config variants, I also saw:

[Warning] infra/conf: congestion & up & down & udphop move to finalmask/quicParams

So I removed deprecated up/down/udphop fields and reduced the config to a more minimal shape. The behavior remained the same.

So the key symptom is:

Hysteria inbound starts successfully and receives client UDP packets, but sends no visible response packets during QUIC handshake, resulting in client timeout and no useful server-side logs.

Reproduction Method

1. Start Xray with the Hysteria inbound config shown below
2. Confirm startup log shows successful bind on UDP port
3. From a LAN client, connect using a Hysteria2 URL with alpn=h3 and insecure=1
4. Run tcpdump on the server for the Hysteria UDP port
5. Observe incoming UDP packets from client
6. Observe no response UDP packets from server
7. Client always times out

Client config

Minimal obfuscated client URL used for LAN testing:

hysteria2://********-****-****-****-************@SERVER_LAN_IP:PORT/?alpn=h3&insecure=1#hy2-lan-test

Server config

{
  "log": {
    "loglevel": "debug"
  },
  "inbounds": [
    {
      "tag": "hy2-in",
      "listen": "0.0.0.0",
      "port": PORT,
      "protocol": "hysteria",
      "settings": {
        "version": 2,
        "clients": [
          {
            "auth": "********-****-****-****-************"
          }
        ]
      },
      "streamSettings": {
        "network": "hysteria",
        "security": "tls",
        "tlsSettings": {
          "alpn": [
            "h3"
          ],
          "minVersion": "1.3",
          "maxVersion": "1.3",
          "certificates": [
            {
              "certificateFile": "/etc/xray/certs/server-cert.crt",
              "keyFile": "/etc/xray/certs/server-key.pem"
            }
          ]
        },
        "hysteriaSettings": {
          "version": 2,
          "auth": "********-****-****-****-************",
          "udpIdleTimeout": 60
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "hy2-in"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

Certificate generation

For testing, I used a self-signed certificate and key generated locally on the router.

The files referenced in the config:

"certificateFile": "/etc/xray/certs/server-cert.crt",
"keyFile": "/etc/xray/certs/server-key.pem"

were generated with:

mkdir -p /etc/xray/certs && openssl req -x509 -newkey rsa:2048 -sha256 -nodes -days 365 -keyout /etc/xray/certs/server-key.pem -out /etc/xray/certs/server-cert.crt -subj "/CN=xray/O=Local Xray/C=US"

Verification command:

openssl x509 -in /etc/xray/certs/server-cert.crt -noout -subject -issuer

Result:

subject=CN = xray, O = Local Xray, C = US
issuer=CN = xray, O = Local Xray, C = US

For client-side testing, certificate validation was explicitly relaxed using insecure=1, so this setup is only intended for handshake/connectivity testing, not for production use.

Client log

The client side only shows timeout. No useful additional error beyond connection timeout.

Server log

Xray 26.3.27 (Xray, Penetrates Everything.) ...
[Info] infra/conf/serial: Reading config: &{Name:/tmp/...json Format:json}
[Debug] app/log: Logger started
[Debug] app/proxyman/inbound: creating stream worker on 0.0.0.0:PORT
[Warning] core: Xray 26.3.27 started

In an earlier config variant, I also saw:

[Warning] infra/conf: congestion & up & down & udphop move to finalmask/quicParams

After removing those deprecated fields, startup still succeeds and the timeout behavior remains unchanged.

tcpdump evidence

Command used:

tcpdump -ni any "host CLIENT_LAN_IP and udp port PORT"

Observed packet capture:

17:08:27.xxx In IP CLIENT_LAN_IP.53XXX > SERVER_LAN_IP.PORT: UDP, length 1280
17:08:27.xxx In IP CLIENT_LAN_IP.53XXX > SERVER_LAN_IP.PORT: UDP, length 1280
17:08:27.xxx In IP CLIENT_LAN_IP.53XXX > SERVER_LAN_IP.PORT: UDP, length 1280
17:08:28.xxx In IP CLIENT_LAN_IP.53XXX > SERVER_LAN_IP.PORT: UDP, length 1280
17:08:29.xxx In IP CLIENT_LAN_IP.53XXX > SERVER_LAN_IP.PORT: UDP, length 1280
...

What is missing is any reverse traffic such as:

SERVER_LAN_IP.PORT > CLIENT_LAN_IP.53XXX

So the server clearly receives client UDP packets, but appears not to send any response packets at all during handshake.

Related issues / similar reports checked

I searched existing Xray-core issues and found some related Hysteria/Hysteria2 reports, but none appears to exactly match this case.

1. The Hysteria2 client-side clientManager bug #5911 - The Hysteria2 client-side clientManager bug
   The Hysteria2 client-side clientManager bug #5911
   This appears to be a client-side auth caching bug when multiple Hysteria2 outbounds share the same destination. It does not seem to match this case, because here I am testing a server-side inbound and the failure happens already at the handshake stage.

2. hysteria2 obfs (Salamander) #5712 - hysteria2 obfs (Salamander)
   hysteria2 obfs (Salamander) #5712
   This one also involves timeout behavior with packets reaching the server, but it is specifically about Salamander obfuscation compatibility. My test case does not use Salamander or other obfuscation masks.

3. [Bug] Hysteria2 出站使用自签证书配合 pinnedPeerCertSha256 连接失败 #5655 - self-signed cert / pinnedPeerCertSha256 related issue
   [Bug] Hysteria2 出站使用自签证书配合 pinnedPeerCertSha256 连接失败 #5655
   This is also not an exact match. That case is more explicitly TLS/certificate related, while in my case the key symptom is that the server receives UDP packets but does not appear to send any response packets at all during handshake.

4. Proxy: Add Hysteria 2 inbound & transport (supports listening port range, Salamander finalmask) #5679 - Add Hysteria 2 inbound & transport
   Proxy: Add Hysteria 2 inbound & transport (supports listening port range, Salamander finalmask) #5679
   I used this as an important reference for config shape. My test config is aligned with that server-side format:

   • protocol: "hysteria"
   • settings.version = 2
   • streamSettings.network = "hysteria"
   • streamSettings.hysteriaSettings.version = 2
   • security = "tls"
   • alpn = ["h3"]

So while there are related Hysteria/Hysteria2 issues, I could not find an existing report that exactly matches this specific symptom set:

inbound starts successfully, UDP packets reach the server, but no response packets are sent back and the client always times out.

Expected behavior

One of the following should happen:

1. successful Hysteria v2 / QUIC handshake, or
2. explicit server-side log explaining why the handshake is rejected, or
3. at least visible response packets from server during handshake attempts

Actual behavior

• client always times out
• server receives UDP packets
• server does not appear to send response packets
• server logs show startup only, with no useful handshake-level error

Notes

What I believe is already ruled out:

• not a basic firewall/routing issue, because incoming UDP packets clearly reach the server
• not a config parse/startup failure, because Xray starts and binds successfully
• not caused by deprecated up/down/udphop, because removing them does not change the behavior
• not confusion about protocol: "hysteria2", because current Xray server-side config clearly expects protocol: "hysteria" with version: 2

I would like to know whether:

1. this is a known issue in Hysteria inbound on current Xray Core,
2. some required field is still missing from the minimal config above,
3. or there is a platform-specific limitation/bug that would explain a completely silent non-response during QUIC handshake.

[Fangliding]

客户端config不完整

[shadow-enthusiast]

客户端config不完整

Sorry, but what do you mean by "incomplete" here? I've provided a complete template configuration to reproduce.

[Fangliding]

provide the actual running complete file

[shadow-enthusiast]

Here is complete config:

{
  "log": {
    "loglevel": "debug"
  },
  "inbounds": [
    {
      "tag": "hy2-in",
      "listen": "0.0.0.0",
      "port": 45873,
      "protocol": "hysteria",
      "settings": {
        "version": 2,
        "clients": [
          {
            "auth": "9c4a1f2e-63d7-4c91-b8a2-7d13f5e2c944"
          }
        ]
      },
      "streamSettings": {
        "network": "hysteria",
        "security": "tls",
        "tlsSettings": {
          "alpn": [
            "h3"
          ],
          "minVersion": "1.3",
          "maxVersion": "1.3",
          "certificates": [
            {
              "certificateFile": "/etc/xray/certs/xray-cert.crt",
              "keyFile": "/etc/xray/certs/xray-key.pem"
            }
          ]
        },
        "hysteriaSettings": {
          "version": 2
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "hy2-in"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

For testing I also generated a self-signed cert locally with:

mkdir -p /etc/xray/certs && openssl req -x509 -newkey rsa:2048 -sha256 -nodes -days 365 -keyout /etc/xray/certs/xray-key.pem -out /etc/xray/certs/xray-cert.crt -subj "/CN=test-node/O=Local Test/C=US"

Client side was tested with a Hysteria2 URL in this shape:

hysteria2://9c4a1f2e-63d7-4c91-b8a2-7d13f5e2c944@10.23.47.91:45873/?alpn=h3&insecure=1#hy2-lan-test

[Fangliding]

你可以用一行 hysteria2://9c4a1f2e-63d7-4c91-b8a2-7d13f5e2c944@10.23.47.91:45873/?alpn=h3&insecure=1#hy2-lan-test 直接运行 xray 吗？都说了完整config

[shadow-enthusiast]

The previous comment already contains the complete server-side JSON config.

The hysteria2://... line there is only the client-side test URL with pseudo ip address, not a replacement for the server config and tested by Hiddify and Happ clients.

If by “actual running complete config” you mean a live server config that is directly reachable and can be tested by connecting to my server, I cannot provide that kind of access. However, the posted config can be used as-is for testing in another environment.

[Fangliding]

不遵照模板
不处理第三方客户端

[shadow-enthusiast]

Sorry, but if you think that this is not XRay core bug, which mobile clients you suggest to try with Hysteria2 inbound and the mentioned config?

[shadow-enthusiast]

Ok, if I got it correct: currently Xray Hysteria2 inbound works only with other Xray nodes.

Is so @Fangliding, Could you please clarify whether Xray Hysteria2 inbound is expected (feature request) to interoperate with third-party Hysteria2 clients?

As a user, I would normally expect protocol-level compatibility from Hysteria2, similar to what people often expect from VLESS across different clients/implementations.

My current observation is:

• Hiddify client → Hiddify Manager: works
• Hiddify client → Xray VLESS inbound: works
• Hiddify client → Xray Hysteria2 inbound: does not work

So the question is:

• Is this interoperability expected and incompatibility should be treated as a bug?
• Or is Xray Hysteria2 inbound effectively intended only for Xray-side ecosystem usage?

If third-party compatibility is not an intended goal, it would be very helpful to document that clearly.

Thanks.

[Fangliding]

我们不可能有精力去把你的 Hiddify 或者任何图形客户端 下载下来然后弄出来测试 只有提供启动xray用的config 在纯xray上严谨复现我们才能处理
如果你认为 xray 实现的互操作性存在问题 也至少提供启动 hysteria 官方核心的配置 不过通常此类问题先例不多（hysteria是很长时间内我们引入的唯一一个外部代理协议）我们会看情况处理

[HaoweiCh]

server: 127.0.0.1:30443

auth: 3A2EA4D05BD24B8A9922452DF8073141

tls:
  sni: localhost
  insecure: true

quic:
  maxIdleTimeout: 6s
  keepAlivePeriod: 3s
  disablePathMTUDiscovery: false

fastOpen: true
lazy: true

http:
  listen: 127.0.0.1:2010

socks5:
  listen: 127.0.0.1:2011

tun:
  name: utun123
  mtu: 1500
  timeout: 1m
  address:
    ipv4: 100.100.100.101/30
    ipv6: 2001::ffff:ffff:ffff:fff1/126
  route:
    ipv4Exclude:
      - 127.0.0.0/8
      - 192.168.18.1/16
      - 8.209.231.122/32
      - 223.5.5.5/32
#      - 223.6.6.6/32
#      - 180.76.76.76/32
    ipv6Exclude:
      - "::1/128"

---

{
      "tag": "hy2-in",
      "listen": "127.0.0.1",
      "port": 30443,
      "protocol": "hysteria",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "domainsExcluded": [
          "courier.push.apple.com",
          "Mijia Cloud"
        ]
      },
      "settings": {
        "version": 2,
        "clients": [
          {
            "auth": "3A2EA4D05BD24B8A9922452DF8073141"
          }
        ]
      },
      "streamSettings": {
        "network": "hysteria",
        "security": "tls",
        "tlsSettings": {
          "alpn": [
            "h3"
          ],
          "certificates": [
            {
              "certificateFile": "/opt/homebrew/etc/xray/hy2.local.crt",
              "keyFile": "/opt/homebrew/etc/xray/hy2.local.key"
            }
          ]
        },
        "hysteriaSettings": {
          "version": 2,
          "auth": "3A2EA4D05BD24B8A9922452DF8073141",
          "udpIdleTimeout": 60
        }
      }
    }

---

2026/06/15 19:09:14.247019 [Info] [3155099416] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/hysteria: connection ends > proxy/hysteria: failed to transport all UDP response > datagram support disabled
2026/06/15 19:09:14.261085 [Info] [761947907] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/hysteria: connection ends > proxy/hysteria: failed to transport all UDP response > datagram support disabled
2026/06/15 19:09:14.296472 [Info] [229645923] app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/hysteria: connection ends > proxy/hysteria: failed to transport all UDP response > datagram support disabled

---

almost all UDP connection denied. client hysteria server X-ray