Перейти к содержимому
НовостиGitHubСкачать

Совместимость

Citrus проверяют два набора интеграционных тестов в test/interop. Оба запускают настоящие бинарники других проектов против Citrus, собранного из ветки, и идут в CI на каждый PR, который трогает транспорты, TLS, листенеры или исходящие.

  • Клиенты mihomo → сервер Citrus. Официальные релизы mihomo в роли клиента: так работают приложения пользователей Mikan (Mikan, ClashFest, Clash Verge и подобные).
  • Xray ↔ Citrus. Xray v26.10.10 в обе стороны: клиент Citrus против сервера Xray и клиент Xray против сервера Citrus.

Бинарники закреплены по версии и SHA-256, так что подменённый релиз тест не пропустит.

В CI два релиза mihomo: v1.19.32 (его использует панель, это последний стабильный релиз) и v1.19.31. Один раз локально прогнали ещё v1.19.24 (апрель 2026), в CI его нет.

Каждый случай отправляет через туннель GET и POST на 256 КиБ к локальному эхо-серверу и сверяет SHA-256 тела. Где протокол несёт UDP, туда и обратно идут датаграммы по 16, 512 и 1200 байт. По логу сервера тест проверяет, что трафик прошёл через входящий Citrus. Для VLESS, Trojan, Shadowsocks 2022 с несколькими пользователями и Hysteria2 тест ещё смотрит GET /traffic/users: трафик записан тому пользователю, который его отправил, и никому больше.

Входящий Citrus ← исходящий mihomo TCP UDP Статистика v1.19.32 v1.19.31 v1.19.24
VLESS + REALITY + Vision, классический X25519 ✓ ✓ ✓ работает работает работает
VLESS + REALITY + Vision, клиент с support-x25519mlkem768 ✓ ✓ работает работает работает
VLESS + REALITY + Vision, сервер с mldsa65-seed, классический клиент ✓ ✓ работает работает работает
то же, клиент с support-x25519mlkem768 ✓ ✓ работает работает работает
REALITY с require-x25519mlkem768 и mldsa65-seed, клиент с ML-KEM ✓ работает работает работает
REALITY с require-x25519mlkem768, классический клиент — отклонён, как и должен отклонён отклонён
VLESS XHTTP stream-one поверх TLS (h2) ✓ ✓ работает работает работает
VLESS XHTTP packet-up поверх TLS (h2) ✓ ✓ работает работает работает
VLESS XHTTP packet-up поверх TLS (HTTP/1.1) ✓ ✓ работает работает работает
VLESS WebSocket + TLS ✓ ✓ работает работает работает
VLESS gRPC + TLS ✓ ✓ работает работает работает
VLESS Vision + TLS ✓ ✓ работает работает работает
Trojan TLS ✓ ✓ ✓ работает работает работает
Shadowsocks 2022 (2022-blake3-aes-128-gcm), один пользователь ✓ ✓ работает работает работает
Shadowsocks 2022, несколько пользователей (EIH, iPSK:uPSK) ✓ ✓ ✓ работает работает работает
Hysteria2 ✓ ✓ ✓ работает работает работает
TUIC v5 ✓ ✓ работает работает работает
AnyTLS ✓ ✓ работает работает работает
TrustTunnel поверх HTTP/2 ✓ ✓ работает работает работает
TrustTunnel поверх QUIC ✓ ✓ работает работает работает
Snell v3 ✓ ✓ работает работает работает
Snell v4 ✓ ✓ работает работает не работает (клиент)
Snell v5 ✓ ✓ работает работает не работает (клиент)
Mieru, транспорт TCP ✓ ✓ работает работает работает
Mieru, транспорт UDP ✓ ✓ работает работает работает
Sudoku ✓ ✓ работает работает работает
HTTP с авторизацией ✓ работает работает работает
SOCKS5 с авторизацией ✓ ✓ работает работает работает
mixed с авторизацией, как HTTP ✓ работает работает работает
mixed с авторизацией, как SOCKS5 ✓ ✓ работает работает работает
SOCKS5 с неверным паролем — отклонён, как и должен отклонён отклонён

Несовместимостей на стороне Citrus не нашлось.

  • Snell v4 и v5 нужен свежий клиент. mihomo v1.19.24 знает только v1–v3 и отказывается разбирать собственный конфиг с version: 4. С v1.19.31 и новее v4 и v5 работают. У клиента mihomo по умолчанию version: 1, у сервера Citrus — version: 4, поэтому в подписке версию нужно указывать явно, а для старых клиентов выбирать v3.
  • require-x25519mlkem768 пускает только клиентов с ML-KEM. Клиент без support-x25519mlkem768 отправляет только классический key share X25519, и сервер с require-x25519mlkem768: true его не пустит. Так и задумано. Включайте это требование, только если все клиенты умеют X25519MLKEM768: Citrus делает это по умолчанию, mihomo — с support-x25519mlkem768: true.
  • mldsa65-seed на сервере старым клиентам не мешает. У клиентов mihomo нет mldsa65-verify, и лишнюю подпись они просто не проверяют.
  • Протоколы, которые Citrus удалил (см. ниже): с ними подключение не сработает.
  • Протоколы, для которых у Citrus нет входящего: SSH, WireGuard, MASQUE, OpenVPN, Tailscale, EasyTier, ZeroTier, gost relay. В Citrus это только исходящие или серверы сторонних проектов.
  • desync: не протокол, а исходящий DIRECT, приспособленный к сетям с DPI-фильтрацией, поэтому проверять совместимость не с чем, см. Исходящий desync.
  • ShadowQUIC: входящий в Citrus есть, но в матрицу пока не включён.

Свои HTTP-запросы — загрузку подписок, proxy-providers, rule-providers, geodata — Citrus отправляет с User-Agent из global-ua. По умолчанию это два токена через пробел:

clash.meta/<версия> citrus/<версия>

Например, clash.meta/v1.0.0-beta.3 citrus/v1.0.0-beta.3. Токен clash.meta/ стоит первым, поэтому правила панелей (Remnawave, Marzban, 3x-ui и другие), которые узнают клиента mihomo по началу строки, работают как раньше. Отличить Citrus от mihomo панель может по второму токену:

\bcitrus/(\S+)

Первая группа — версия ядра. Если global-ua задан в конфиге, он отправляется как есть, без токена citrus/.

Набор тестов против Xray v26.10.10. Ключи берутся у самого Xray (xray x25519, mldsa65, uuid, tls ech), цель REALITY — локальный TLS 1.3 сервер с цепочкой больше 4 КБ, чтобы в сертификат поместилась подпись ML-DSA-65.

Случай Варианты
Клиент Citrus → сервер Xray: VLESS + Vision + REALITY с mldsa65Seed отпечатки chrome, firefox, safari, ios; неверный mldsa65-verify должен отказать
Клиент Xray → сервер Citrus: mldsa65-seed и require-x25519mlkem768 chrome, firefox; неверный mldsa65Verify должен отказать
Клиент Citrus → сервер Xray: XHTTP (REALITY, h2) packet-up, stream-one, stream-up, путь с ?query, x-padding-bytes: "0-0"
Клиент Xray → сервер Citrus: XHTTP packet-up, выгрузка через GET, данные в заголовках
XHTTP поверх HTTP/3 (TLS, alpn: [h3]) в обе стороны packet-up, stream-one, stream-up; клиент Xray ещё и с выгрузкой через GET и данными в заголовках
ECH в обе стороны (echServerKeys Xray и ech-key Citrus) верный и неверный конфиг; неверный должен отказать, это доказывает, что ECH действительно работал
VLESS + gRPC поверх REALITY в обе стороны

Отдельно проверяли, но не держат в CI: выгрузку и загрузку по 64 МиБ через XHTTP stream-one, stream-up и packet-up с Xray в обеих ролях.

Citrus убрал протоколы, которые не нужны VPN-сервису и для которых есть современная замена.

Удалено Чем заменить
VMess (вместе с транспортами mKCP, mekya и TLSMirror) VLESS: Vision, REALITY, VLESS Encryption, транспорты WebSocket, gRPC, XHTTP
ShadowsocksR Shadowsocks с AEAD-шифром или 2022-blake3-*
Потоковые шифры Shadowsocks (rc4-md5, aes-ctr, aes-cfb, chacha20, chacha20-ietf, xchacha20, table, rc4) AEAD (aes-128-gcm, aes-256-gcm, chacha20-ietf-poly1305) или 2022-blake3-*
v2ray-plugin VLESS или Trojan поверх WebSocket и TLS
Hysteria v1 Hysteria2
TUIC v4 (token) TUIC v5 (uuid и password)
mKCP Протоколы поверх QUIC: Hysteria2, TUIC v5

Как ведут себя старые конфиги и подписки, описано в переходе с mihomo.