Zapytania za Cloudflare padają dokładnie po 100 sekundach

Plany Free i Pro w Cloudflare ograniczają odpowiedź HTTP przechodzącą przez proxy do 100 sekund. Jeśli model do tego czasu nie skończy, połączenie zostaje zerwane, niezależnie od twoich własnych timeoutów. Streaming tego unika, bo bajty ciągle napływają; pojedyncze długie generowanie bez streamingu – nie.

Co widzisz

error code: 524
Requests consistently fail at 100-101 seconds, never at 90 or 120
The same request succeeds when sent directly to the origin IP
A streaming response stops mid-sentence with no error in the server log
read ECONNRESET / IncompleteRead after a long pause

Dlaczego tak się dzieje

Zdradza to precyzja. Problemy sieciowe i timeouty serwera źródłowego są rozrzucone – raz padają po 40 sekundach, raz po 180. Limit proxy uruchamia się zawsze przy tej samej liczbie. Jeśli twoje błędy skupiają się przy 100–101 sekundach, przestań szukać we własnym stosie.

Czas mierzony jest do pierwszego bajtu treści odpowiedzi, dlatego streaming zachowuje się tak inaczej. Z stream: true pierwszy token zwykle przychodzi po sekundzie, dwóch i zegar nawet nie zbliża się do limitu. Bez streamingu proxy czeka na całe generowanie – a długi łańcuch rozumowania czy obraz 4K łatwo przekracza 100 sekund.

To wyjaśnia też mylący objaw: na serwerze zapytanie wygląda na udane. Upstream skończył, serwer źródłowy zalogował 200, tokeny zostały naliczone. Zerwany został tylko odcinek między proxy a klientem. W logu użycia dostawcy zobaczysz zakończone, rozliczone zapytanie, którego twój klient nigdy nie dostał.

Sprawdź, czy to ta przyczyna

Zmierz, kiedy pojawia się błąd. Dokładna liczba jest diagnozą:

time curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' \
  'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"model":"YOUR_MODEL","messages":[{"role":"user","content":"Write a 3000 word essay."}]}'

Około 100s razem z 524 to potwierdza. Uruchom to samo zapytanie z "stream": true – jeśli się zakończy, jedynym problemem był limit.

Jak to naprawić

Włącz streamingNajskuteczniejsze pojedyncze rozwiązanie i zwykle zmiana w jednej linii. stream: true w treści zapytania; każde duże SDK to obsługuje. Pierwszy token przychodzi w sekundy, więc 100-sekundowe okno nigdy się nie otwiera.
Użyj endpointu, który nie idzie przez proxyNiektórzy dostawcy publikują osobną nazwę hosta API omijającą CDN właśnie z tego powodu. Jeśli twój ją ma, kieruj na nią długie wywołania, a stronę zostaw pod nazwą z proxy.
Ogranicz pracę na zapytanieUstawienie max_tokens na wartość, którą model zdąży wygenerować w oknie, zamienia niewidoczne ucięcie w przewidywalne zatrzymanie. Podział jednego długiego generowania na kilka wywołań daje to samo i łatwiej go ponawiać.
Nie podnoś timeoutu klienta i nie uznawaj sprawy za załatwionąPołączenie jest zrywane przed tobą. Timeout klienta 300 sekund da ten sam błąd 200 sekund później — tylko wolniej odtworzysz objaw.

APICLAN publikuje https://api.apiclan.us/v1 właśnie na taki przypadek — ten endpoint nie stoi za 100-sekundowym limitem proxy, więc długie generowania bez streamingu się kończą. Główny endpoint https://apiclan.us/v1 nadaje się do streamingu i wszystkiego, co odpowiada szybko.

Powiązane

Unexpected token '<' przy wywołaniu API zgodnego z OpenAI 401 invalid API key – gdy klucz wygląda dobrze, a i tak nie działa

Ostatnio sprawdzono 2026-10-01. Napisane na podstawie problemów zdiagnozowanych na działającej bramce zgodnej z OpenAI, a nie zebrane z innych stron.