Windows 10: same VLESS/Reality config works in Invincible Man but fails in Hiddify 2.5.7 (System Proxy, Local Proxy, and VPN/TUN); local proxy returns TLS handshake failure

[JohnnyShelton]

Search first

• I searched and no similar issues were found

Platform/OS

Windows

OS version

Windows 10 22H2 (OS Build 19045.6456)

Hiddify Version

2.5.7

What Happened?

The same VLESS/Reality config works on the same Windows PC in Invincible Man, but fails in Hiddify 2.5.7.

This issue affected many users at the same time on two different servers around the night of April 1. The server/config itself is likely not the root cause, because the exact same config works in Invincible Man on the same PC and network.

Observed behavior in Hiddify:

• System Proxy mode reaches the server and opens multiple TCP connections to SERVER_IP:443.
• VPN (experimental) / TUN mode also creates tun0 and can open TCP connections to SERVER_IP:443.
• However, real traffic does not work reliably.
• DNS inside Hiddify is unstable/failing depending on settings.
• Local mixed proxy on 127.0.0.1:12334 accepts CONNECT, but TLS handshake fails afterwards.

What was verified:

• Test-NetConnection to SERVER_IP:443 succeeds.
• netstat shows multiple ESTABLISHED connections from Hiddify.exe to SERVER_IP:443.
• In VPN/TUN mode, Test-NetConnection succeeds through tun0.
• The same config works in Invincible Man on the same Windows machine.
• In Hiddify local mixed proxy test, HTTP CONNECT is accepted, but TLS handshake fails immediately after that.

This makes it look like the problem is in Hiddify 2.5.7 Windows client stack / local proxy / TUN handling rather than in the server config itself.

Minimal Reproducible Example (MRE)

1. Install Hiddify 2.5.7 on Windows 10 22H2.
2. Import a working VLESS/Reality config/subscription.
3. Connect in System Proxy mode.
4. Run:
   • tasklist | findstr /I Hiddify
   • netstat -ano | findstr "SERVER_IP:443"
   • powershell -Command "Test-NetConnection SERVER_IP -Port 443"
5. Observe that Hiddify opens multiple ESTABLISHED TCP connections to SERVER_IP:443.
6. Switch to VPN (experimental) mode.
7. Observe that tun0 appears and Test-NetConnection to SERVER_IP:443 succeeds through tun0.
8. Test DNS and traffic:
   • nslookup www.google.com 172.19.0.2
   • nslookup web.telegram.org 172.19.0.2
   • curl.exe -k -I https://1.1.1.1
   • curl.exe -I https://www.google.com
   • curl.exe -I https://web.telegram.org
9. Test local mixed proxy:
   • curl.exe -x http://127.0.0.1:12334 -I https://www.google.com
   • curl.exe -x http://127.0.0.1:12334 -I https://web.telegram.org
   • curl.exe --socks5-hostname 127.0.0.1:12334 -I https://www.google.com
   • curl.exe --socks5-hostname 127.0.0.1:12334 -I https://web.telegram.org
10. Compare with Invincible Man on the same PC using the same config.
11. Observe that the same config works in Invincible Man, but fails in Hiddify 2.5.7.

Expected Behavior

The same VLESS/Reality config should work in Hiddify 2.5.7 the same way it works in Invincible Man on the same Windows PC and network.

Expected behavior:

• System Proxy mode should carry real traffic successfully.
• VPN/TUN mode should carry real traffic successfully.
• DNS queries through local DNS 172.19.0.2 should work consistently.
• Local mixed proxy on 127.0.0.1:12334 should allow HTTPS traffic without TLS handshake failure.

Additional Context

Important comparison:

• Same Windows PC
• Same network
• Same config
• Same server
• Works in Invincible Man
• Fails in Hiddify 2.5.7

This issue appeared suddenly around the night of April 1 and affected many users at the same time on two different servers.

That strongly suggests the problem is not in one broken server config, because the same config still works in another Windows client on the same machine.

From testing, the problem is reproducible in:

• System Proxy mode
• Local mixed proxy mode (127.0.0.1:12334)
• VPN/TUN mode

The most important sign is that local mixed proxy accepts CONNECT (HTTP/1.1 200 Connection established) but then TLS fails immediately with schannel handshake failure.

Application Config Options

Hiddify 2.5.7
Windows 10 22H2

Tested settings:

• Mode: System Proxy / VPN (experimental)
• Mixed port: 12334
• Transparent proxy port: 12335
• Local DNS port: 16450
• Strict route: ON
• TUN implementation: tested both gvisor and system
• DNS routing: tested ON and OFF
• Remote DNS: tested udp://1.1.1.1 and 8.8.8.8
• Direct DNS: tested 1.1.1.1 and 8.8.8.8
• Remote domain strategy: ipv4_only
• Direct domain strategy: ipv4_only
• IPv6 routing: OFF
• WARP: OFF
• TLS fragmentation: OFF
• TLS Mixed SNI Case: OFF
• TLS Padding: OFF

Best intermediate result:

• Remote DNS = 8.8.8.8
• Direct DNS = 8.8.8.8
• DNS routing = ON

With that setup, DNS partially recovered in one test, but actual traffic still failed.

Relevant log output

Examples from Hiddify logs:

ERROR outbound/urltest[auto]: context deadline exceeded

ERROR dns: exchange failed for web.telegram.org. IN A: context deadline exceeded

ERROR dns: exchange failed for SUBSCRIPTION_DOMAIN. IN A: dial tcp SERVER_IP:443: operation was canceled

ERROR dns: exchange failed for www.google-analytics.com. IN A: dial tcp SERVER_IP:443: operation was canceled

WARN outbound/urltest[auto]: TCP URLTest Outbound auto (PROFILE_NAME § 0) failed to connect for 15 times ==> test proxies again!

Local mixed proxy test results:

• curl.exe -x http://127.0.0.1:12334 -I https://www.google.com
  -> HTTP/1.1 200 Connection established
  -> curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

• curl.exe -x http://127.0.0.1:12334 -I https://web.telegram.org
  -> HTTP/1.1 200 Connection established
  -> curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

• curl.exe --socks5-hostname 127.0.0.1:12334 -I https://www.google.com
  -> curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

• curl.exe --socks5-hostname 127.0.0.1:12334 -I https://web.telegram.org
  -> curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

VPN/TUN mode symptoms:

• nslookup www.google.com 172.19.0.2 may work in one test
• nslookup web.telegram.org 172.19.0.2 times out
• curl.exe -k -I https://1.1.1.1 -> Recv failure: Connection was reset
• curl.exe -I https://www.google.com -> may fail with TLS reset or DNS failure
• curl.exe -I https://web.telegram.org -> host resolve failure

Are you willing to submit a PR? If you know how to fix the bug.

• I'm willing to submit a PR (Thank you!)