XTLS/Xray-core · warning
auth method not supported.
Error message
auth method not supported.
What it means
Thrown during the SOCKS5 client handshake when the server's selected auth method byte differs from the one Xray offered. If Xray offered 0x02 (username/password, because credentials are configured) and the server picks 0x00 or 0xFF, the methods are incompatible and the handshake aborts. Marked AtWarning.
Source
Thrown at proxy/socks/protocol.go:464
b := buf.New()
defer b.Release()
common.Must2(b.Write([]byte{socks5Version, 0x01, authByte}))
if err := buf.WriteAllBytes(writer, b.Bytes(), nil); err != nil {
return nil, err
}
b.Clear()
if _, err := b.ReadFullFrom(reader, 2); err != nil {
return nil, err
}
if b.Byte(0) != socks5Version {
return nil, errors.New("unexpected server version: ", b.Byte(0)).AtWarning()
}
if b.Byte(1) != authByte {
return nil, errors.New("auth method not supported.").AtWarning()
}
if authByte == authPassword {
b.Clear()
account := request.User.Account.(*Account)
common.Must(b.WriteByte(0x01))
common.Must(b.WriteByte(byte(len(account.Username))))
common.Must2(b.WriteString(account.Username))
common.Must(b.WriteByte(byte(len(account.Password))))
common.Must2(b.WriteString(account.Password))
if err := buf.WriteAllBytes(writer, b.Bytes(), nil); err != nil {
return nil, err
}
b.Clear()
if _, err := b.ReadFullFrom(reader, 2); err != nil {
return nil, err
}View on GitHub (pinned to 7d214f8b09)
Solutions
- Match the client to the server: either add username/password to the Xray outbound servers entry, or disable auth on the SOCKS5 server.
- Confirm the remote server actually supports username/password auth (RFC 1929) if credentials are configured.
- Test the pair with curl --socks5 host:port -U user:pass to isolate which side mismatches.
- Check for middleboxes stripping the method negotiation.
Example fix
// before: outbound without credentials against an auth-requiring server
{ "protocol": "socks", "settings": { "servers": [ { "address": "s.example", "port": 1080 } ] } }
// after
{ "protocol": "socks", "settings": { "servers": [ { "address": "s.example", "port": 1080, "users": [ { "user": "u", "pass": "p" } ] } ] } } Defensive patterns
Strategy: validation
Validate before calling
// probe supported auth methods during a preflight handshake
conn.Write([]byte{0x05, 0x02, 0x00}) // offer no-auth + userpass
reply := make([]byte, 2)
io.ReadFull(conn, reply)
if reply[1] == 0xFF {
return errors.New("server accepts none of our auth methods")
} Try / catch
if err := client.Process(ctx, link, dialer); err != nil {
if strings.Contains(err.Error(), "auth method not supported") {
// align credentials presence with server requirements
}
} Prevention
- Keep client credentials presence in sync with server auth mode.
- Document the auth mode next to each server entry in config.
- Use preflight probes in connection managers that hot-switch outbounds.
When it happens
Trigger: Xray outbound 'socks' has auth configured but the remote SOCKS5 server requires no auth or doesn't support username/password auth (or vice versa: no auth configured client-side while the server demands 0x02); server replies 0xFF 'no acceptable methods'.
Common situations: Server upgraded and its auth requirement changed; credentials omitted from the Xray outbound settings while the server enforces auth; mixed config where users array exists server-side but the client sends none.
Related errors
- no matching auth method
- invalid username or password
- socks 4 is not allowed when auth is required.
- failed to read auth methods
- failed to read username and password for authentication
AI-assisted analysis of XTLS/Xray-core@7d214f8b09 (2026-08-15).
Data as JSON: /api/errors/896a584f452db574.
Report an issue: GitHub.