`inbounds`: входящие подключения

Цель

Разобрать блок inbounds как точку входа трафика в Xray и показать, какие параметры влияют на сеть, безопасность, протокол и диагностику.

Теория

inbounds — это массив входящих подключений. Каждый элемент описывает, где Xray слушает трафик, какой protocol применяет, какие настройки протокола использует и какие transport/security параметры ожидает от клиента.

В 3x-ui многие действия с inbound выполняются через UI, но итоговая логика все равно сводится к Xray inbound: listen, port, protocol, settings, streamSettings, tag, sniffing и другим связанным полям.

История

Inbound-модель отражает модульную архитектуру Xray: разные протоколы могут использовать общий каркас входящего объекта, но иметь собственные settings. Поэтому нельзя переносить параметры VLESS в Trojan или Shadowsocks механически.

Архитектура

Типовой inbound:

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 1080,
      "protocol": "vless",
      "settings": {},
      "streamSettings": {},
      "tag": "vless-in",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    }
  ]
}

Связь с общим потоком:

client -> inbound -> routing -> outbound -> target

Настройка

Перед созданием inbound нужно определить:

кто будет подключаться;
какой protocol используется;
какой transport и security layer нужны;
какой порт слушает Xray;
открыт ли этот порт firewall;
нужен ли sniffing;
какой tag будет использовать routing.

Для production inbound должен быть минимально открыт: только нужный адрес, порт, protocol и пользователи. Любая публикация нового inbound наружу требует security review.

Разбор параметров

Параметр	Назначение	Риск
`listen`	адрес прослушивания	значение по умолчанию слушает все интерфейсы
`port`	порт или допустимое представление порта	конфликт портов ломает запуск или доступность
`protocol`	inbound-протокол	определяет структуру `settings`
`settings`	настройки выбранного протокола	нельзя переносить между протоколами без проверки
`streamSettings`	transport/security настройки	mismatch с клиентом ломает соединение
`tag`	идентификатор inbound	используется routing-правилами
`sniffing`	попытка определить домен/протокол	влияет на routing и диагностику

Типовые ошибки

слушать 0.0.0.0 там, где достаточно 127.0.0.1;
открыть порт в firewall до проверки security layer;
забыть tag, а затем не понять, почему routing-правило не работает;
включить transport только на сервере или только на клиенте;
перепутать ошибку протокола с ошибкой TLS/REALITY;
использовать один client ID или пароль для всех пользователей.

Безопасность

Inbound — это внешняя поверхность Xray. Нужно проверять адрес прослушивания, порт, firewall, protocol settings, transport security, уникальность клиентских секретов и возможность отзыва доступа. В 3x-ui создание inbound через UI должно считаться security-sensitive действием.

Чек-лист

Определен protocol inbound.
Проверены listen и port.
Firewall соответствует выбранному порту.
settings сверены с документацией конкретного protocol.
streamSettings совпадают с клиентом.
tag понятен и используется routing-правилами.
Есть план отзыва клиентского доступа.

Источники для сверки

Project X: Inbound Proxy — https://xtls.github.io/en/config/inbound.html

inbounds: входящие подключения