Прокси для исходящих запросов

Некоторые внешние API (BillManager, VMmanager, биллинги хостеров) принимают только определённые исходящие IP, а часть провайдеров (например, Telegram, VK) может быть заблокирована на сетевом уровне. SupportHub позволяет настроить прокси-профили и привязать их к каналам -- запросы пойдут через выбранный прокси, а не напрямую.

Два уровня: глобальный и workspace

• Глобальный -- управляется администратором платформы в /admin/proxies. Сюда добавляются прокси, доступные всем workspace платформы. Здесь же включается режим «enforced» (см. ниже) и заводятся исключения по каналам.
• Workspace -- управляется владельцем workspace в /settings/proxies. Эти прокси видит только конкретный workspace -- удобно, когда у клиента свой VPN/выходной узел.

Привязка к типу канала

Каждый прокси-профиль можно ограничить конкретным типом канала: billmgr, vmmanager, email, telegram, vk. Профиль «для всех» (any) подходит к любому каналу, профиль «только telegram» не будет предложен при настройке BillManager-канала. Это снижает риск ошибочно выбрать прокси, который выходит не из той сети.

Поддерживаемые схемы

• http://
• https://
• socks5:// -- обрабатывается через httpx[socks].

http://user:pass@proxy.example.com:8080
https://proxy.example.com:443
socks5://user:pass@proxy.example.com:1080

Порядок разрешения

Когда канал отправляет исходящий запрос, бэкенд проходит по шагам и берёт первое подходящее правило:

1. proxy_force_disabled для канала -- админская «аварийная» пометка. Если она стоит, прокси для этого канала вообще не применяется (даже enforced). Дальше идёт либо workspace-pick, либо прямой выход.
2. Workspace-private pick -- если workspace выбрал свой собственный (не глобальный) прокси для канала, он заменяет enforced. Это легитимный способ для workspace перенаправить трафик на собственный узел.
3. Enforced global для типа канала -- если админ платформы включил «принудительный» режим для kind (например, «все Telegram-каналы ходят через этот прокси»), применяется он.
4. Workspace pick (глобальный профиль) -- если workspace выбрал глобальный прокси, он применяется только если для типа канала нет enforced.
5. Нет прокси -- запрос идёт напрямую через дефолтный egress бэкенда.

Режим enforced

Enforced -- это режим, в котором админ платформы фиксирует обязательный прокси для всех каналов определённого типа. Полезно, когда нужно прогнать через одну сеть весь Telegram-трафик платформы, или гарантировать, что VK-каналы не выходят с прямого IP.

• Workspace может заменить enforced на свой собственный workspace-private прокси -- но не может отключить enforced полностью.
• Полностью обойти enforced может только админ платформы -- через страницу «Исключения по каналам» (флаг proxy_force_disabled на конкретный канал).

BillManager: два отдельных слота

BM-канал хранит две независимые ссылки на прокси: верхнеуровневый proxy_id для API BillManager и вложенный vmmanager.proxy_id для API VMmanager. На практике панель биллинга и панель виртуализации часто стоят в разных сетях, и операторы могут захотеть пустить их через разные маршруты -- например, BM напрямую, а VMmanager через приватный VPN.

channel.config = {
  "url": "https://bill.example.com",
  "login": "...",
  "password": "...",
  "proxy_id": 12,            // -> для запросов к BillManager
  "vmmanager": {
    "url": "https://vmm.example.com",
    "login": "...",
    "password": "...",
    "proxy_id": 17           // -> для запросов к VMmanager
  }
}

Статус интеграции

• Работает: BillManager, VMmanager, VK -- все исходящие запросы каналов уважают порядок разрешения и enforced-режим.
• В разработке: Telegram -- 87 различных мест в коде вызывают httpx в обход общего клиента; их нужно обернуть в proxy-aware factory. Поле proxy_id на канале уже сохраняется и видно в UI, но в трафик пока не уходит.
• В разработке: Email (SMTP/IMAP) -- стандартные библиотеки не понимают SOCKS, нужна обёртка через python-socks. Слот proxy_id на email-канале уже есть и хранится.