Strona główna → Pomoc

Timeout 524 przy długich zapytaniach do API

524 generuje reverse proxy lub CDN stojący przed API, a nie model. Wyzwala się, gdy serwer źródłowy nie wyśle pierwszego bajtu odpowiedzi w ustalonym oknie czasowym – zwykle 100 sekund.

Co widzisz

Dlaczego tak się dzieje

Kluczowy szczegół: zegar mierzy czas do pierwszego bajtu, a nie łączny czas trwania. Odpowiedź ze streamingiem zaczyna wysyłać dane niemal od razu, więc może trwać wiele minut i nigdy nie trafić w limit. Zapytanie bez streamingu z długą fazą rozumowania nie wysyła nic, dopóki całkiem nie skończy – i właśnie takie zostaje ucięte.

Dlatego błąd wygląda na losowy. Ten sam prompt przechodzi, gdy akurat szybko się kończy, i pada, gdy model dłużej myśli; koreluje to z głębokością rozumowania, a nie z czymkolwiek, co zmieniłeś.

Sprawdź, czy to ta przyczyna

Uruchom to samo zapytanie ze streamingiem i bez. Jeśli jedno przeżywa, a drugie nie, znalazłeś przyczynę:

# non-streaming — vulnerable to the time-to-first-byte limit
curl -sS -X POST 'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL","stream":false,"messages":[...]}'

# streaming — first byte arrives in well under a second
  -d '{"model":"MODEL","stream":true,"messages":[...]}'

Streaming daje też dużo lepszy sposób zawodzenia: jeśli coś pójdzie nie tak w połowie, masz przynajmniej częściową odpowiedź, zamiast tracić całe wywołanie.

Jak to naprawić

  1. Włącz streamingTo rozwiązuje problem całkowicie dla niemal każdego zastosowania i jest zmianą w jednej linii. Większość SDK i narzędzi agentowych i tak domyślnie używa streamingu.
  2. Użyj bezpośredniego endpointu, jeśli dostawca go maNiektórzy dostawcy publikują host API omijający ich CDN właśnie z powodu tego limitu. Jeśli długie wywołania bez streamingu są nieuniknione, właśnie do tego służy.
  3. Podziel pracęJeśli pojedyncze wywołanie naprawdę potrzebuje minut rozumowania, zanim cokolwiek zwróci, zwykle taniej i pewniej jest rozbić je na etapy z punktami kontrolnymi.
W APICLAN zapytania ze streamingiem nigdy nie są buforowane, więc ich to nie dotyczy. Dla długich wywołań bez streamingu jest bezpośredni endpoint https://api.apiclan.us/v1 bez takiego limitu.

Powiązane

Unexpected token '<' przy wywołaniu API zgodnego z OpenAI401 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.