Proxy wychodzące
Części modeli nie da się osiągnąć bezpośrednio z serwerów w Rosji. Żeby nie zamieniało się to w ręczne ustawianie u każdego operatora, AiHummer wydaje adres proxy wychodzącego przy instalacji i sam decyduje, którą drogą wysłać żądanie.
Najważniejsze w dwóch zdaniach
Adres proxy przychodzi od dostawcy i ląduje w prywatnym pliku na serwerze — w
gateway.env nie jest przechowywany i nie trafia do dzienników. Jeśli proxy nie
zostało ustawione albo jest niedostępne, żądanie idzie wprost: instancja
pracuje dalej, zamiast stanąć.
Co dokąd idzie
| Dokąd | Jak idzie |
|---|---|
| Model zewnętrzny (dostawca zagraniczny) | przez proxy, jeśli jest skonfigurowane i zdatne |
| Ten sam model przy niedostępnym proxy | wprost, z ostrzeżeniem w dzienniku |
localhost, *.localhost, wewnętrzny adres instancji |
zawsze wprost, z pominięciem proxy |
Ostatni wiersz jest ważny: odwołanie instancji do samej siebie nigdy nie zostaje zawinięte w proxy, inaczej wywołania lokalne zależałyby od zewnętrznego kanału.
Droga zapasowa: brak proxy nie jest odmową
Do wersji 1.2.8 nieustawione lub niedziałające proxy oznaczało błąd żądania. Teraz zachowanie jest inne:
- proxy skonfigurowane i zdatne → żądanie idzie przez nie;
- proxy nieskonfigurowane → żądanie idzie wprost, a w dzienniku raz zapisuje się ostrzeżenie z przyczyną „nie skonfigurowano”;
- proxy skonfigurowane, ale wartość jest niezdatna → żądanie idzie wprost, a przyczyną w ostrzeżeniu jest „konfiguracja niezdatna”.
Ostrzeżenie pojawia się raz na uruchomienie, a nie przy każdym żądaniu: inaczej zalałoby dziennik i przestałoby być czytane.
:::note Droga wprost jest wariantem zapasowym, a nie zamiennikiem proxy. Jeśli dostawca nie przyjmuje żądań z rosyjskich adresów, żądanie wprost również do niego nie przejdzie — ale odmówi już dostawca i w odpowiedzi będzie widać właśnie to, a nie ogólne „nie udało się zastosować ustawienia”. :::
Gdzie przechowywany jest adres
Wartość żyje w prywatnym pliku, którego ścieżkę zadaje
AIHUMMER_OUTBOUND_PROXY_URL_FILE. Wymagania wobec pliku:
- ścieżka bezwzględna;
- zwykły plik, uprawnienia nie szersze niż
0600; - rozmiar do 4096 bajtów.
Zrobiono tak celowo: adres proxy zawiera hasło, więc nie powinien leżeć w
gateway.env, który bywa czytany i kopiowany podczas obsługi.
:::caution
Zmienna AIHUMMER_OUTBOUND_PROXY_URL, trzymająca adres „wprost w wartości”,
istnieje wyłącznie dla kompilacji deweloperskich. Kompilacje wydawnicze jej nie
czytają — na produkcji przyjmowana jest wyłącznie ścieżka do pliku.
:::
Jakie adresy są przyjmowane
Sprawdzenie jest takie samo i w chwili wydania ustawienia, i w chwili jego użycia, więc niezdatna wartość zostaje odrzucona od razu, zamiast zamienić się później w „modele zagraniczne znowu nie działają” bez jednego wiersza w dzienniku.
Przyjmowane są: schemat http lub https, niepusty host, bez ciągu zapytania,
bez fragmentu, bez ścieżki (poza /).
🔴 Gołe http na nielokalnym hoście jest odrzucane celowo. Po
nieszyfrowanym http nagłówek Proxy-Authorization idzie jawnym tekstem przy
każdym połączeniu — czyli hasło proxy wyciekałoby nieprzerwanie. Dla nielokalnego
hosta używaj https.
Jak sprawdzić, co się dzieje
# 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
Odmowa zastosowania ustawienia nazywa przyczynę — „nie skonfigurowano”, „konfiguracja niezdatna” — zamiast ogólnego „nie udało się zastosować”. To odróżnia „adres nie dojechał” od „adres dojechał, ale jest błędny”.
Co ma zrobić operator
Zwykle nic: adres jest wydawany przy instalacji. Wtrącenie potrzebne jest w dwóch przypadkach.
- Własne proxy zamiast dostawcy. Włóż adres do prywatnego pliku z
uprawnieniami
0600i wskaż ścieżkę wAIHUMMER_OUTBOUND_PROXY_URL_FILE, a następnie zrestartuj bramę. - Proxy w ogóle niepotrzebne (instancja stoi tam, skąd modele są dostępne bezpośrednio). Nic nie trzeba wskazywać: nieustawione proxy oznacza żądanie wprost.