Proxy sortant

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

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

Certaines modèles ne sont pas accessibles directement depuis les serveurs en Russie. Afin que cela ne se transforme pas en configuration manuelle pour chaque opérateur, AiHummer **fournit l'adresse du proxy sortant lors de l'installation** et décide lui-même du chemin à emprunter pour envoyer la requête. ## L'essentiel en deux phrases L'adresse du proxy provient du fournisseur et est placée dans un fichier privé sur le serveur — elle n'est pas stockée dans `gateway.env` et n'apparaît pas dans les journaux. Si le proxy n'est pas défini ou est indisponible, la requête est envoyée **directement** : l'instance continue de fonctionner, sans s'arrêter. ## Qui va où | Où | Comment ça se passe | | --- | --- | | Modèle externe (fournisseur étranger) | via le proxy, s'il est configuré et approprié | | Même modèle si le proxy est indisponible | **directement**, avec un avertissement dans le journal | | `localhost`, `*.localhost`, adresse interne de l'instance | **toujours directement**, en contournant le proxy | La dernière ligne est importante : l'appel de l'instance à elle-même n'est jamais encapsulé dans le proxy, sinon les appels locaux dépendraient du canal externe. ## Chemin de secours : l'absence de proxy — pas de refus Jusqu'à la version 1.2.8, un proxy non défini ou défaillant entraînait une erreur de requête. Le comportement a maintenant changé : - proxy configuré et approprié → la requête passe par celui‑ci ; - proxy **non configuré** → la requête est envoyée directement, le journal enregistre une fois un avertissement avec la raison «non configuré» ; - proxy configuré, mais **valeur inappropriée** → la requête est envoyée directement, la raison dans l'avertissement — «configuration inappropriée». L'avertissement est affiché **une fois par lancement**, et non à chaque requête : sinon il inonderait le journal et deviendrait illisible. :::note Le chemin direct est une option de secours, pas un remplacement du proxy. Si le fournisseur n'accepte pas les requêtes provenant d'adresses russes, la requête directe vers lui échouera — mais c'est le fournisseur qui refusera, et la réponse le montrera clairement, plutôt qu'un message générique «impossible d'appliquer la configuration». ::: ## Où l'adresse est stockée La valeur réside dans un **fichier privé**, dont le chemin est indiqué par `AIHUMMER_OUTBOUND_PROXY_URL_FILE`. Exigences pour le fichier : - chemin absolu ; - fichier ordinaire, permissions **pas plus larges que `0600`** ; - taille maximale de 4096 octets. Cela est fait intentionnellement : l'adresse du proxy contient un mot de passe, il ne doit donc pas se trouver dans `gateway.env`, qui est lu et copié lors de la maintenance. :::caution La variable `AIHUMMER_OUTBOUND_PROXY_URL` contenant l'adresse «directement dans la valeur» n'existe que pour les builds de développement. **Les builds de production ne la lisent pas** — en production, seul le chemin vers le fichier est accepté. ::: ## Quels adresses sont acceptées La validation est identique au moment de la délivrance de la configuration et au moment de l'utilisation, ainsi une valeur inappropriée est rejetée immédiatement, plutôt que de se transformer plus tard en «les modèles étrangers ne fonctionnent plus» sans aucune ligne dans le journal. Acceptées : le schéma `http` ou `https`, un hôte non vide, sans chaîne de requête, sans fragment, sans chemin (sauf `/`). 🔴 **Le `http` simple sur un hôte non local est rejeté intentionnellement.** Avec le `http` non chiffré, l'en-tête `Proxy-Authorization` est envoyé en texte clair à chaque connexion — le mot de passe du proxy fuirait continuellement. Pour un hôte non local, utilisez `https`. ## Comment vérifier ce qui se passe ```bash # Что сейчас настроено (значение не печатается — только факт настройки) aihummer doctor # Журнал шлюза: предупреждение о прямом пути, если прокси не применён journalctl -u aihummer-gateway -n 200 | grep -i прокси ``` Le refus d'appliquer la configuration indique **la raison** — «non configuré», «configuration inappropriée» — au lieu d'un message générique «impossible d'appliquer». Cela distingue «l'adresse n'est pas arrivée» de «l'adresse est arrivée, mais est incorrecte». ## Que doit faire l'opérateur En général — rien : l'adresse est fournie lors de l'installation. Une intervention est nécessaire dans deux cas. 1. **Votre propre proxy à la place de celui du fournisseur.** Placez l'adresse dans un fichier privé avec les permissions `0600` et indiquez le chemin dans `AIHUMMER_OUTBOUND_PROXY_URL_FILE`, puis redémarrez la passerelle. 2. **Le proxy n'est pas du tout nécessaire** (l'instance se trouve à un endroit où les modèles sont accessibles directement). Aucun paramètre n'est requis : l'absence de proxy signifie une requête directe.