Один порт для многих инбаундов

Ingress — это инбаунд, который занимает один порт, обычно 443, и передаёт каждое соединение другому инбаунду по имени, которое запросил клиент, по его ALPN или по пути. Так VLESS с REALITY, Trojan поверх WebSocket и другие могут делить порт 443 на одном узле, и у каждого остаются свои пользователи, статистика и ограничения.

Для чего он нужен

• Открыт только один порт, обычно 443, а предложить на нём нужно несколько инбаундов.
• Разные имена на одном адресе: a.example.com ведёт в один инбаунд, b.example.com — в другой.
• Ответ как у обычного веб-сервера на всё, что не является вашим пользователем.

У ingress нет своих пользователей, и он никогда не появляется в подписке. В ней появляются его потомки, с портом ingress.

Создание

1. Сначала создайте инбаунды, которые будут стоять за ним (потомков). См. Инбаунды.
2. Входящие → Добавить, тип ingress. Port по умолчанию 443.
3. Выберите режим на вкладке TLS (см. ниже).
4. На вкладке Protocol добавьте правило для каждого потомка кнопкой Добавить правило, затем Запасной маршрут.
5. Нажмите Сохранить и добавьте ingress и его потомков в один и тот же шаблон.

Правила

Правила проверяются сверху вниз, и срабатывает первое совпавшее, поэтому ставьте самые конкретные выше (Вверх, Вниз).

Поле	С чем сравнивается
Имя сервера (SNI)	имя, которое запросил клиент. Точное совпадение или суффикс, если имя начинается с точки (.example.com). Пустое поле совпадает с любым именем
ALPN	согласованный прикладной протокол, например h2 или http/1.1
Путь	путь, который запрашивает потомок WebSocket или HTTPUpgrade, чтобы несколько потомков могли делить одно имя. Завершающий / совпадает с префиксом. Только в режиме терминации
Отправлять в	инбаунд-потомок или Внешний адрес… с полями Адрес и Порт

Все условия одного правила должны совпасть; несколько значений в одном условии — это альтернативы. Для внешнего адреса PROXY-протокол передаёт настоящий адрес клиента серверу, который его читает, например nginx. Инбаунду-потомку это не нужно: он всегда видит настоящий адрес клиента.

Запасной маршрут получает все соединения, не совпавшие ни с одним правилом. Задавайте его всегда; доступные варианты зависят от режима.

Два режима: какая сторона выполняет TLS

TLS может выполнять ровно одна сторона: ingress или его потомки.

Режим просмотра: TLS на ingress выключен

Ingress только читает первое сообщение TLS-рукопожатия, в котором есть имя сервера и ALPN, и передаёт соединение дальше целиком. Каждый потомок сам выполняет TLS: со своим сертификатом или с REALITY.

• У каждого потомка должен быть TLS или REALITY, иначе маршрутизировать не по чему.
• Правила Путь недоступны: всё после рукопожатия зашифровано.
• Запасным маршрутом может быть Внешний адрес… с настоящим веб-сервером, который тогда отвечает своим сертификатом.

В этом режиме за ingress ставят инбаунды REALITY.

Режим терминации: TLS на ingress

Ingress сам завершает TLS-рукопожатие с сертификатом со своей вкладки TLS и передаёт каждому потомку открытый поток. У потомков нет TLS.

• Становятся доступны правила Путь для потомков, которые говорят на HTTP/1.1 (WebSocket, HTTPUpgrade). gRPC и всё, что работает поверх HTTP/2, передают путь в сжатом виде; разделяйте их по ALPN.
• Правило ALPN совпадает только с протоколом, который предлагает сам ingress. Добавьте его в список ALPN на вкладке TLS ingress, иначе панель не даст сохранить.
• Запасной маршрут или любое правило может быть Имитация веб-ответа…, которая отвечает как обычный веб-сервер: Фиксированную страницу, Настоящий сайт (проксирование) или Каталог файлов (абсолютный путь на узле). Настоящий сайт убедительнее всего.
• Ссылки пользователей берут настройки TLS у ingress, потому что настройки самого потомка до клиента не доходят.

Имитация ответа, которую не удаётся настроить (нет каталога, неверный адрес), отключает только своё правило; остальные потомки продолжают работать.

Потомки

За ingress могут стоять инбаунды таких типов: VLESS, VMess, Trojan, AnyTLS, Snell, Shadowsocks, ShadowTLS, Sudoku, SSH, SOCKS, HTTP, mixed и direct. UDP-протоколы (Hysteria2, TUIC и остальные), NaiveProxy, Mieru, MTProxy, TrustTunnel и другой ingress не могут, и панель отклоняет правило, которое указывает на такой инбаунд.

Потомок может существовать двумя способами:

Потомок	Доступен	В подписках
Со своим портом	напрямую и через ingress	две записи: своя и запись с именем <child>-<ingress>
Без порта	только через ingress	одна запись, через ingress

Запись через ingress несёт порт ingress и имя сервера из правила. Инбаунд без порта, на который не ведёт ни одно правило ingress, помечается в списке инбаундов как Недоступен и не попадает в подписки, пока вы не дадите ему порт или правило.

Панель показывает предупреждение, но всё равно сохраняет, если TLS пары не подходит к режиму (TLS на обеих сторонах или ни на одной) или правило указывает на несуществующий инбаунд. Ingress часто создают раньше потомков, поэтому исправляйте это по ходу.

Шаблоны и узлы

Шаблон может нести только часть потомков ingress: один шаблон предлагает VLESS и Trojan на 443, другой только VLESS. На каждом узле правило, чьего потомка там нет, отбрасывается, а ingress без правил не попадает в конфигурацию.

За CDN

Сам ingress нельзя поставить за фронт, а потомка, подходящего для CDN, можно. CDN открывает к узлу собственное соединение с именем хоста фронта, а не потомка, поэтому в правиле должно быть имя хоста фронта (или суффикс вроде .cdn.example.com). Иначе соединение уходит в запасной маршрут, и пользователь не доходит до цели. Панель предупреждает об этом на фронте. См. Доменный фронтинг.

Дополнительно

ClientHello timeout (дополнительное поле на вкладке Protocol) — сколько ingress ждёт первое сообщение рукопожатия от клиента, прежде чем сдаться.

Связанные страницы

• VLESS с REALITY — самый частый потомок в режиме просмотра
• Инбаунды — страница инбаундов
• Сертификаты — сертификат, с которым ingress выполняет терминацию