Адаптивный proxy-router для локального TCP-трафика
Courier — это локальный SOCKS5/HTTP CONNECT proxy-router, который для каждого соединения решает, как лучше идти к назначению: напрямую или через upstream-прокси.
Главная идея проекта простая: proxy должен быть исключением, а не режимом по умолчанию.
В обычной схеме весь трафик часто отправляется через прокси или VPN просто потому, что так проще настроить. Но на практике это избыточно: локальные адреса, приватные сети, внутренние сервисы и множество обычных направлений прекрасно работают напрямую. Проксировать их дороже, медленнее и менее прозрачно.
Courier делает иначе. Он сначала проверяет, пригоден ли direct-путь, учитывает локальность назначения, явные правила маршрутизации и накопленные доказательства из кэша. Только если прямой маршрут непригоден или политика явно требует прокси, соединение отправляется через настроенный upstream.
Что делает Courier
Courier поднимает локальные SOCKS5- и HTTP CONNECT-listener’ы и становится точкой принятия решений для TCP-трафика.
Он не пытается заменить VPN, не реализует собственный туннель и не проксирует всё подряд. Его задача уже: принять локальное соединение, классифицировать назначение и выбрать наиболее разумный маршрут.
Локальные и приватные адреса идут напрямую. Явные правила имеют приоритет. Для неизвестных или потенциально проблемных направлений Courier может проверить direct-доступность, использовать GeoIP-логику, посмотреть кэш предыдущих решений и только после этого выбрать proxy.
Результат — меньше лишнего proxy-трафика, меньше ручных исключений и более понятное поведение сети.
Чем проект отличается
Большинство proxy-настроек работают грубо: либо всё напрямую, либо всё через прокси, либо через большой набор ручных правил.
Courier построен вокруг более точной модели: direct first, proxy when needed.
Он не спрашивает только «есть ли правило для домена?». Он пытается понять, есть ли реальная причина использовать proxy именно для этого назначения прямо сейчас.
Это делает проект полезным в сетях с выборочной фильтрацией, нестабильной связностью, разными upstream-прокси и большим количеством локального трафика, который нельзя бездумно отправлять наружу.
Объяснимость решений
Одна из важных частей Courier — команда courier explain.
Она позволяет понять, почему конкретный домен или адрес пойдёт напрямую или через proxy, не открывая туннель и не меняя состояние кэша.
Это превращает маршрутизацию из чёрного ящика в проверяемую систему: видно, какое правило сработало, что показала проверка direct-пути, какие данные взяты из кэша, как определена локальность и почему выбран конкретный итоговый verdict.
Для сетевого инструмента это критично. Если система сама принимает решения, она должна уметь объяснить эти решения инженеру.
Архитектура маршрутизации
Внутри Courier используется последовательный pipeline принятия решений:
ограничения → domain_routing → [manual|cache off] → no_proxy(DNS) → кэш (proxied→accessible→temporary) → локальность (+probe для foreign) → direct-check → proxyСначала система отбрасывает неподдерживаемые варианты и пропускает локальные назначения напрямую. Затем применяет явные правила domain_routing, проверяет свежие записи в кэше, оценивает локальность назначения и при необходимости выполняет проверку direct-доступности.
Только после этого выбирается upstream-прокси — и только если direct-маршрут признан неподходящим.
Такой подход делает поведение предсказуемым: решение не размазано по случайным условиям, а проходит через фиксированный порядок проверок.
Для чего это нужно
Courier подходит для сценариев, где обычный «всё через proxy» слишком груб.
Например, когда часть ресурсов доступна напрямую, часть деградирует, часть должна идти через конкретный upstream, а локальные сервисы и приватные сети нельзя трогать вообще.
В такой среде ручные PAC-файлы, browser-only proxy-настройки или простые SOCKS-прокси быстро становятся неудобными. Courier добавляет слой автоматического выбора маршрута, но оставляет поведение наблюдаемым и управляемым.
Текущий статус
Проект уже имеет базовую архитектуру маршрутизации, профили политики, локальные SOCKS5/HTTP CONNECT listener’ы, кэш решений, проверку upstream-здоровья, GeoIP-логику и CLI для диагностики.
Это не VPN и не универсальная система обхода ограничений. Это минимальный, объяснимый и управляемый proxy-router, который решает одну конкретную задачу: не использовать proxy там, где он не нужен, и использовать его там, где direct-путь реально непригоден.