Inbounds и Outbounds в sing-box: как читать путь трафика

Что такое inbounds и outbounds в sing-box?

В sing-box inbounds определяют точки входа трафика в ядро, а outbounds — точки выхода. Проще говоря, inbound «слушает» сетевые соединения (от локальных приложений или других прокси), а outbound отправляет трафик к целевым серверам — например, к вашему VPS или напрямую в интернет.

Понимание этой пары — основа диагностики. Если вы видите конфиг, но не понимаете, куда уходит трафик, вы не сможете быстро определить, почему не работает сайт или почему скорость упала.

Как устроен JSON-конфиг sing-box

Типичный конфиг sing-box содержит секции inbounds и outbounds, а также route, dns и другие опциональные блоки. Все они взаимодействуют так:

• inbounds — список серверов, которые принимают соединения;
• outbounds — список серверов, которые устанавливают исходящие подключения;
• route — правила, которые решают, какой outbound использовать для каждого соединения;
• dns — отвечает за разрешение доменов и может отправлять DNS-запросы через отдельные outbounds.

Таким образом, путь трафика выглядит так: приложение → inbound → route → outbound → сервер в интернете. Обратный путь аналогичен.

Путь трафика: от клиента до сервера

Когда вы включаете sing-box на своём устройстве, он создаёт локальный прокси (например, SOCKS5 на порту 1080). Это inbound-часть. Приложение использует этот прокси, и sing-box через route решает, куда направить соединение: на прямой выход (direct) или через удалённый прокси (vless, shadowsocks и т.д.).

На удалённом сервере sing-box тоже работает: он получает соединение через свой inbound, затем применяет свои правила маршрутизации и отправляет трафик через выбранный outbound. Важно понимать, что «путь трафика» — это не только ваш клиент, но и каждый узел в цепочке.

Читаем конфигурацию: разбор ключевых полей

Чтобы прочитать путь трафика, нужно уметь расшифровывать JSON. Рассмотрим минимальный inbound:

{
  "type": "http",
  "listen": "127.0.0.1",
  "listen_port": 1080
}

• type — протокол, например http, socks, tun, mixed;
• listen — адрес, на котором inbound принимает соединения;
• listen_port — порт.

Аналогично outbound имеет type и параметры сервера:

{
  "type": "vless",
  "server": "example.com",
  "server_port": 443,
  "uuid": "ваш-uuid",
  "tls": { "enabled": true }
}

Здесь server и server_port указывают, куда идёт соединение. Если в outbound есть блок transport, он описывает протокол передачи (WebSocket, gRPC и т.д.).

Роль route и DNS в маршрутизации

Route — это мозг sing-box. Он содержит список правил, каждое из которых соответствует определённому условию (домен, IP, порт, геоданные) и указывает, какой outbound использовать. Правила проверяются последовательно, сверху вниз. Если ни одно правило не совпало, применяется outbound по умолчанию, указанный в final.

{
  "route": {
    "rules": [
      { "domain_suffix": [".google.com"], "outbound": "proxy" }
    ],
    "final": "direct"
  }
}

DNS также влияет на путь трафика. Например, если в dns задан сервер, а в route используется правило по домену, sing-box сначала выполнит DNS-запрос, затем примет решение. Некоторые типы inbound (например, TUN) перехватывают DNS-запросы и направляют их отдельно.

TUN-режим и перехват трафика

TUN — это виртуальный сетевой интерфейс. Когда вы задаёте inbound типа tun, sing-box получает все сетевые пакеты системы (или заданной маршрутизацией). Это позволяет работать в режиме «прозрачного прокси». В этом случае путь трафика начинается не с конкретного порта, а с перехвата пакетов на уровне ядра ОС.

Для TUN важно задать диапазоны IP, которые должны идти через прокси, а также исключения. Иногда TUN-режим используется вместе с HTTP/SOCKS-inbound, чтобы захватывать и локальные приложения, и системный трафик.

VLESS и transport: как устроен исходящий поток

Протокол VLESS — это современный прокси-протокол с минимальным оверхедом, но он не задаёт транспорт. Транспорт определяет, как именно пакеты VLESS упаковываются в TCP, UDP или HTTP. Например:

• ws — WebSocket, часто используется через CDN;
• grpc — HTTP/2 gRPC;
• httpupgrade — HTTP upgrade;
• quic — QUIC (UDP).

Если вы читаете конфиг, обратите внимание на URL-адрес или объект transport: именно там скрываются детали подключения к серверу. Например, для ws нужно указать host и path. Поле tls описывает параметры TLS-шифрования, включая SNI и ALPN.

Типичные ошибки при чтении пути трафика

• Игнорирование заголовка route: трафик может уходить на direct, хотя вы думаете, что он проксируется.
• Неправильное понимание listen_port и server_port: первый — порт локального входа, второй — порт удалённого сервера.
• Путаница между inbound и outbound на сервере: сервер тоже использует outbounds для дальнейшей передачи, например в цепочке.
• Забывают про DNS: даже если вы отправили домен на прокси, DNS-запрос может уйти напрямую, что раскроет ваши действия.

Практический пример: разбор профиля

Рассмотрим часть конфига для клиента:

{
  "inbounds": [
    { "type": "mixed", "listen_port": 1080 }
  ],
  "outbounds": [
    { "type": "direct", "tag": "direct" },
    { "type": "vless", "tag": "proxy", "server": "vps.example.com", ... }
  ],
  "route": {
    "final": "proxy",
    "rules": [ { "domain_suffix": [".ru"], "outbound": "direct" } ]
  }
}

Путь трафика: приложение → mixed-инбаунд (порт 1080) → route проверяет домен → если домен .ru, то direct, иначе proxy → outbound подключается к vps.example.com.

На сервере свой конфиг, где inbound = vless, а outbound = direct. Таким образом, полный путь от приложения до сайта включает два sing-box инстанса.

Читать путь трафика — значит понимать, на каком этапе происходит та или иная обработка. Начните с простой схемы: локальный inbound, route, outbound. Затем добавьте серверный inbound и outbound, и вы получите полную картину.