Proxy de ieșire
O parte dintre modele nu pot fi atinse direct de pe servere din Rusia. Ca acest lucru să nu se transforme într-o configurare manuală la fiecare operator, AiHummer emite adresa proxy-ului de ieșire la instalare și decide singur pe ce cale trimite cererea.
Esențialul în două fraze
Adresa proxy-ului vine de la furnizor și ajunge într-un fișier privat de pe
server — nu se păstrează în gateway.env și nu ajunge în jurnale. Dacă proxy-ul
nu e setat sau nu e accesibil, cererea pleacă direct: instanța continuă să
lucreze, nu se oprește.
Ce unde merge
| Unde | Cum merge |
|---|---|
| Model extern (furnizor străin) | prin proxy, dacă e configurat și utilizabil |
| Același model cu proxy-ul inaccesibil | direct, cu un avertisment în jurnal |
localhost, *.localhost, adresa internă a instanței |
întotdeauna direct, ocolind proxy-ul |
Ultimul rând contează: apelul instanței către ea însăși nu e împachetat niciodată prin proxy, altfel apelurile locale ar depinde de un canal extern.
Calea de rezervă: lipsa proxy-ului nu e un refuz
Până la versiunea 1.2.8, un proxy nesetat sau nefuncțional însemna o cerere eșuată. Acum comportamentul e altul:
- proxy configurat și utilizabil → cererea trece prin el;
- proxy neconfigurat → cererea pleacă direct, iar în jurnal se scrie o singură dată un avertisment cu motivul „neconfigurat”;
- proxy configurat, dar cu valoare inutilizabilă → cererea pleacă direct, iar motivul din avertisment e „configurație inutilizabilă”.
Avertismentul se scrie o singură dată pe pornire, nu la fiecare cerere: altfel ar inunda jurnalul și nimeni nu l-ar mai citi.
:::note Calea directă e o soluție de rezervă, nu un înlocuitor al proxy-ului. Dacă furnizorul nu acceptă cereri de la adrese rusești, nici cererea directă nu va trece — dar refuzul va veni de la furnizor și exact asta se va vedea în răspuns, nu un „nu s-a putut aplica setarea” generic. :::
Unde se păstrează adresa
Valoarea trăiește într-un fișier privat, a cărui cale e dată de
AIHUMMER_OUTBOUND_PROXY_URL_FILE. Cerințe pentru fișier:
- cale absolută;
- fișier obișnuit, drepturi nu mai largi de
0600; - dimensiune de cel mult 4096 de octeți.
E făcut intenționat: adresa proxy-ului conține o parolă, deci nu trebuie să stea
în gateway.env, care e citit și copiat la mentenanță.
:::caution
Variabila AIHUMMER_OUTBOUND_PROXY_URL, cu adresa pusă „direct în valoare”,
există doar pentru versiunile de dezvoltare. Versiunile de lansare nu o
citesc — în producție se acceptă exclusiv calea către fișier.
:::
Ce adrese se acceptă
Verificarea e aceeași și în momentul emiterii setării, și în momentul folosirii, deci o valoare inutilizabilă e respinsă imediat, în loc să se transforme mai târziu în „modelele străine iar nu merg”, fără niciun rând în jurnal.
Se acceptă: schema http sau https, gazdă nevidă, fără șir de interogare, fără
fragment, fără cale (în afară de /).
🔴 Un http gol pe o gazdă nelocală e respins intenționat. Peste http
necriptat, antetul Proxy-Authorization pleacă în clar la fiecare conexiune —
adică parola proxy-ului s-ar scurge continuu. Pentru o gazdă nelocală foloseşte
https.
Cum verifici ce se întâmplă
# What is configured right now (the value is never printed — only whether it is set)
aihummer doctor
# Gateway log: the direct-route warning when the proxy was not applied
journalctl -u aihummer-gateway -n 200 | grep -i proxy
Refuzul de a aplica setarea numește motivul — „neconfigurat”, „configurație inutilizabilă” — în loc de un „nu s-a putut aplica” generic. Asta deosebește „adresa nu a ajuns” de „adresa a ajuns, dar e greșită”.
Ce trebuie să facă operatorul
De obicei nimic: adresa se emite la instalare. Intervenția e necesară în două cazuri.
- Proxy propriu în locul celui de la furnizor. Pune adresa într-un fișier
privat cu drepturi
0600, indică apoi calea înAIHUMMER_OUTBOUND_PROXY_URL_FILEși repornește gateway-ul. - Proxy deloc necesar (instanța stă acolo de unde modelele sunt accesibile direct). Nu trebuie indicat nimic: un proxy nesetat înseamnă cerere directă.