Unexpected Socks5 proxy

[jamesolasx]

Describe the bug

Gemini report:
The current implementation in tcp_server.rs sends a SOCKS5 ReplyError::Succeeded (0x00) immediately after parsing the CONNECT command, but before attempting to establish the actual TCP connection to the target server.

This violates the logic of RFC 1928, where the reply status field (REP) should reflect the result of the connection attempt to the target server.

To Reproduce

Steps to reproduce the behavior:

Expected behavior

Gemini report:
The server should attempt to connect to the target first.

If the connection fails (e.g., Connection Refused), it should send a SOCKS5 reply with REP=0x05 (Connection Refused).

The client should report: (7) Failed to connect to ... Connection refused.

Your wstunnel setup

Paste your logs of wstunnel, started with --log-lvl=DEBUG, and with the command line used

• A client
  ./wstunnel -R "socks5://0.0.0.0:1212" --connection-min-idle 5 wss://server:443
• server
  ./wstunnel server wss://[::]:443
• B client

1. Use a client (e.g., curl) to connect to a closed/unreachable port through the proxy. curl -v -x socks5://Server:1212 192.168.8.111:80 (Assuming 80 is closed)
2. Observe the client error.

Actual Behavior: The client receives a SOCKS5 "Succeeded" reply. Shortly after, the connection is closed because the upstream connection failed.

curl reports: (52) Empty reply from server (or Connection Reset), because it believes the tunnel is established and expects HTTP data.

Expected Behavior: The server should attempt to connect to the target first.

If the connection fails (e.g., Connection Refused), it should send a SOCKS5 reply with REP=0x05 (Connection Refused).

The client should report: (7) Failed to connect to ... Connection refused.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[erebe]

Hello,

This is expected ;)