Plain-text SOCKS5 traffic is typically intercepted and filtered by deep packet inspection (DPI) systems like the GFW. Recently, however, I noticed a strange phenomenon: certain unencrypted packets containing sensitive domain keywords (such as google.com) were able to pass through without being blocked.

After capturing and inspecting the network traffic, I found that this behavior is directly tied to how the SOCKS5 connection is initialized.

1. SOCKS5 Handshake Protocol

When establishing a SOCKS5 connection, the client first sends a Method Selection Request detailing the authentication methods it supports.

A typical request frame looks like this:

05 02 00 02

The byte breakdown is as follows:

• 05: Protocol version (SOCKS5).
• 02: NMETHODS — the number of authentication methods supported (in this case, 2).
• 00 02: METHODS — the supported method identifiers:
  • 0x00: No authentication
  • 0x02: Username/Password

Standard SOCKS5 Authentication Method Identifiers

2. The Anomaly

The anomaly occurs when the client advertises support for GSSAPI (0x01) during the initial negotiation.

Even if the server ultimately selects 0x00 (No Auth) or 0x02 (Username/Password) and GSSAPI is never actually used for the connection, the presence of 0x01 in the client’s initial request causes the GFW to bypass DPI scanning on subsequent payload traffic.

Specifically, when the handshake payload contains:

05 03 00 01 02

(SOCKS5, 3 methods supported: No Auth, GSSAPI, Username/Password)

The GFW appears to ignore the connection from that point forward.

3. Conclusion

This behavior is quite bizarre, though it holds true in recent tests. However, relying on protocol quirks in plain-text SOCKS5 is inherently fragile and unreliable for long-term use. For consistent security and uninhibited traffic flow, encapsulating connection data using encrypted solutions like stunnel or TLS wrappers remains the recommended approach.