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

  1. Set "encryption":"none" — correct for all standard VLESS usage
  2. If you intentionally use the mlkem768x25519plus hybrid, copy the full spec string exactly as produced by the peer/generator (mode, keys, padding segments included)
  3. 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

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


AI-assisted analysis of XTLS/Xray-core@7d214f8b09 (2026-08-15). Data as JSON: /api/errors/b052fb4fbb3bae6f. Report an issue: GitHub.