Исходящий прокси

# Что сейчас настроено (значение не печатается — только факт настройки)
aihummer doctor

# Журнал шлюза: предупреждение о прямом пути, если прокси не применён
journalctl -u aihummer-gateway -n 200 | grep -i прокси

Часть моделей недоступна напрямую с серверов в России. Чтобы это не превращалось в ручную настройку у каждого оператора, AiHummer **выдаёт адрес исходящего прокси при установке** и сам решает, каким путём отправить запрос. ## Главное в двух предложениях Адрес прокси приходит от вендора и ложится в приватный файл на сервере — в `gateway.env` он не хранится и в журналы не попадает. Если прокси не задан или недоступен, запрос уходит **напрямую**: инстанс продолжает работать, а не встаёт. ## Что куда ходит | Куда | Как идёт | | --- | --- | | Внешняя модель (зарубежный провайдер) | через прокси, если он настроен и пригоден | | Та же модель при недоступном прокси | **напрямую**, с предупреждением в журнале | | `localhost`, `*.localhost`, внутренний адрес инстанса | **всегда напрямую**, мимо прокси | Последняя строка важна: обращение инстанса к самому себе никогда не заворачивается в прокси, иначе локальные вызовы зависели бы от внешнего канала. ## Запасной путь: отсутствие прокси — не отказ До версии 1.2.8 незаданный или неработающий прокси означал ошибку запроса. Теперь поведение другое: - прокси настроен и пригоден → запрос идёт через него; - прокси **не настроен** → запрос идёт напрямую, в журнал один раз пишется предупреждение с причиной «не настроен»; - прокси настроен, но **значение непригодно** → запрос идёт напрямую, причина в предупреждении — «настройка непригодна». Предупреждение выводится **один раз за запуск**, а не на каждый запрос: иначе оно залило бы журнал и перестало читаться. :::note Прямой путь — это запасной вариант, а не замена прокси. Если провайдер не принимает запросы с российских адресов, прямой запрос к нему не пройдёт — но откажет уже провайдер, и в ответе будет видно именно это, а не общее «не удалось применить настройку». ::: ## Где хранится адрес Значение живёт в **приватном файле**, путь к которому задаёт `AIHUMMER_OUTBOUND_PROXY_URL_FILE`. Требования к файлу: - абсолютный путь; - обычный файл, права **не шире `0600`**; - размер до 4096 байт. Так сделано намеренно: адрес прокси содержит пароль, поэтому он не должен лежать в `gateway.env`, который читают и копируют при обслуживании. :::caution Переменная `AIHUMMER_OUTBOUND_PROXY_URL` с адресом «прямо в значении» существует только для сборок разработки. **Выпускные сборки её не читают** — в продуктиве принимается исключительно путь к файлу. ::: ## Какие адреса принимаются Проверка одинакова и в момент выдачи настройки, и в момент использования, поэтому непригодное значение отвергается сразу, а не превращается позже в «зарубежные модели опять не работают» без единой строки в журнале. Принимается: схема `http` или `https`, непустой хост, без строки запроса, без фрагмента, без пути (кроме `/`). 🔴 **Голый `http` на нелокальном хосте отвергается намеренно.** По незашифрованному `http` заголовок `Proxy-Authorization` уходит открытым текстом при каждом соединении — то есть пароль прокси утекал бы непрерывно. Для нелокального хоста используйте `https`. ## Как проверить, что происходит ```bash # Что сейчас настроено (значение не печатается — только факт настройки) aihummer doctor # Журнал шлюза: предупреждение о прямом пути, если прокси не применён journalctl -u aihummer-gateway -n 200 | grep -i прокси ``` Отказ применения настройки называет **причину** — «не настроен», «настройка непригодна» — вместо общего «не удалось применить». Это отличает «адрес не доехал» от «адрес доехал, но неверен». ## Что делать оператору Обычно — ничего: адрес выдаётся при установке. Вмешательство нужно в двух случаях. 1. **Свой прокси вместо вендорского.** Положите адрес в приватный файл с правами `0600` и укажите путь в `AIHUMMER_OUTBOUND_PROXY_URL_FILE`, затем перезапустите шлюз. 2. **Прокси не нужен вовсе** (инстанс стоит там, откуда модели доступны напрямую). Ничего указывать не нужно: незаданный прокси означает прямой запрос.