XX-net/XX-Net · warning
socks5 protocol error:%r
Error message
socks5 protocol error:%r
What it means
The X-Tunnel socks5_handler failed while reading the 4-byte SOCKS5 request header (read_bytes(4) threw). The exception is logged as a protocol error and the handler returns, dropping the connection. Typical cause: client disconnected after the greeting, or sent fewer bytes than required.
Source
Thrown at code/default/x_tunnel/local/proxy_handler.py:234
reply = b"\x00\x5a" + addr_pack + struct.pack(">H", port)
sock.send(reply)
if len(self.read_buffer) - self.buffer_start:
g.session.conn_list[conn_id].transfer_received_data(self.read_buffer[self.buffer_start:])
g.session.conn_list[conn_id].start(block=True)
def socks5_handler(self):
sock = self.connection
auth_mode_num = ord(self.read_bytes(1))
data = self.read_bytes(auth_mode_num)
sock.send(b"\x05\x00") # socks version 5, no auth needed.
try:
data = self.read_bytes(4)
except Exception as e:
xlog.debug("socks5 auth num:%d, list:%s", auth_mode_num, utils.str2hex(data))
xlog.warn("socks5 protocol error:%r", e)
return
socks_version = ord(data[0:1])
if socks_version != 5:
xlog.warn("request version:%d error", socks_version)
return
command = ord(data[1:2])
if command != 1: # 1. Tcp connect
xlog.warn("request not supported command mode:%d", command)
sock.send(b"\x05\x07\x00\x01") # Command not supported
return
addrtype_pack = data[3:4]
addrtype = ord(addrtype_pack)
if addrtype == 1: # IPv4
addr_pack = self.read_bytes(4)
addr = socket.inet_ntoa(addr_pack)View on GitHub (pinned to cfa5bc17b6)
Solutions
- Usually benign; increase the read timeout if slow clients are being cut off
- Verify clients complete the full SOCKS5 handshake (version, command, addr-type, address)
- Ignore/log-filter if caused by scanners probing the port
Defensive patterns
Strategy: try-catch
Try / catch
try:
data = self.read_bytes(4)
except Exception as e:
xlog.warn('socks5 protocol error:%r', e)
return Prevention
- Increase read timeout for slow clients
- Verify clients complete the full SOCKS5 request after the greeting
When it happens
Trigger: Client sends SOCKS5 greeting, receives the no-auth reply, then closes or stalls before sending the 4-byte request — read_bytes times out or raises EOF.
Common situations: Probers that only complete half a handshake, real clients behind unstable connections, timeouts from read_bytes being shorter than slow clients need.
Related errors
- request version:%d error
- request version:%d error
- request address type unknown:%d
- request not supported command mode:%d
- do_unwrap_socks connect to x-tunnel for %s:%d proxy fail.
AI-assisted analysis of XX-net/XX-Net@cfa5bc17b6 (2026-08-27).
Data as JSON: /api/errors/c46e67dcd177134b.
Report an issue: GitHub.