XTLS/Xray-core · error
VLESS users: unsupported "encryption": {account.Encryption}
Error message
VLESS users: unsupported "encryption": {account.Encryption} What it means
Thrown by VLessOutboundConfig.Build() when a user's "encryption" value is neither "none", empty (covered by the friendlier sibling error), nor a syntactically valid post-quantum spec of the form mlkem768x25519plus.<mode>.... The validator splits on '.', requires the 'mlkem768x25519plus' prefix plus at least 4 segments with a known mode (native/xorpub/random) and well-formed key/padding segments; anything else — e.g. "auto", "aes-128-gcm" — falls through to this error. Those AEAD values are VMess concepts and do not exist in VLESS.
Source
Thrown at infra/conf/vless.go:374
if len(r) < 20 {
padding += len(r) + 1
continue
}
if b, _ := base64.RawURLEncoding.DecodeString(r); len(b) != 32 && len(b) != 1184 {
return false
}
}
account.Encryption = account.Encryption[27+len(s[2]):]
if padding > 0 {
account.Padding = account.Encryption[:padding-1]
account.Encryption = account.Encryption[padding:]
}
return true
}() && account.Encryption != "none" {
if account.Encryption == "" {
return nil, errors.New(`VLESS users: please add/set "encryption":"none" for every user`)
}
return nil, errors.New(`VLESS users: unsupported "encryption": ` + account.Encryption)
}
user.Account = serial.ToTypedMessage(account)
spec.User = user
break
}
config.Vnext = spec
break
}
return config, nil
}
View on GitHub (pinned to 7d214f8b09)
Solutions
- Set "encryption":"none" — correct for all standard VLESS usage
- If you intentionally use the mlkem768x25519plus hybrid, copy the full spec string exactly as produced by the peer/generator (mode, keys, padding segments included)
- Remove any VMess security values (auto/aes-128-gcm/chacha20-poly1305) from VLESS users
Example fix
// before
"users": [ { "id": "...", "encryption": "auto" } ]
// after
"users": [ { "id": "...", "encryption": "none" } ] Defensive patterns
Strategy: validation
Validate before calling
func validateVlessEncryptionValue(v string) error {
if v == "none" || v == "" { return nil }
s := strings.Split(v, ".")
if len(s) < 4 || s[0] != "mlkem768x25519plus" {
return fmt.Errorf("unsupported encryption %q (VMess values like auto/aes-128-gcm are invalid in VLESS)", v)
}
switch s[1] {
case "native", "xorpub", "random":
return nil
}
return fmt.Errorf("unsupported mlkem mode %q", s[1])
} Type guard
func vlessEncryptionSupported(v string) bool {
if v == "none" { return true }
s := strings.Split(v, ".")
if len(s) < 4 || s[0] != "mlkem768x25519plus" { return false }
switch s[1] {
case "native", "xorpub", "random":
return true
}
return false
} Prevention
- Default every VLESS user to "encryption":"none"
- Never carry VMess security values (auto, aes-128-gcm, chacha20-poly1305) into VLESS
- If using the mlkem768x25519plus hybrid, treat the full spec string as opaque and copy it verbatim from the peer
When it happens
Trigger: "encryption":"auto" or "aes-128-gcm" copied from a VMess account; "chacha20-poly1305"; a malformed post-quantum string like "mlkem768x25519plus" alone (fewer than 4 dot-separated segments).
Common situations: VMess-to-VLESS config conversion leaving the security field in place; following VMess documentation for a VLESS outbound; attempting the experimental mlkem hybrid encryption without the full parameter string from a matching client.
Related errors
- VLESS users: please add/set "encryption":"none" for every us
- VLESS fallbacks: "path" must be empty or start with "/"
- VLESS fallbacks: please fill in a valid value for every "des
- VLESS fallbacks: invalid PROXY protocol version, "xver" only
- VLESS reverse: "tag" can't be empty
AI-assisted analysis of XTLS/Xray-core@7d214f8b09 (2026-08-15).
Data as JSON: /api/errors/b052fb4fbb3bae6f.
Report an issue: GitHub.