Limity szybkości API WEEX: gdzie boty faktycznie trafiają na błąd 429

Większość integracji API WEEX, które zawodzą w produkcji, nie zawodzi z powodu podpisów. Zawodzą, ponieważ bot traktuje "limit szybkości" jako jedną liczbę, podczas gdy WEEX uruchamia dwa niezależne budżety — budżet wagi IP i budżet zleceń na konto — które odnawiają się w różnych odstępach czasu i są raportowane w różnych nagłówkach odpowiedzi. Jeśli zrobisz to źle, otrzymasz błąd HTTP 429 oraz 10-sekundowy ban, zazwyczaj w momencie, gdy zmienność sprawia, że Twoje realizacje mają znaczenie.

Oto skonsolidowana mapa zasad limitów szybkości API WEEX, jakie obowiązują w lipcu 2026 roku, pobrana z dokumentacji spot i futures oraz sprawdzona względem endpointu exchangeInfo dla futures na żywo. Obejmuje ona również to, czego dokumentacja nie wyjaśnia: ile pollingu faktycznie kupują Ci te liczby.

Limity szybkości API WEEX w skrócie

Poniższa tabela łączy zasady, które są obecnie rozproszone w czterech oddzielnych powierzchniach dokumentacji WEEX — ograniczenia dostępu spot, wagi endpointów futures, przegląd WebSocket i lista błędów w centrum pomocy.

Dwa szczegóły w tej tabeli powodują więcej incydentów niż cokolwiek innego.

Po pierwsze, składanie zleceń w ogóle nie zużywa wagi IP — WEEX zwraca 0 w liczniku wagi IP dla tych wywołań. Po drugie, i to jest pułapka, anulowanie i sprawdzanie zleceń nadal podlegają limitom IP. Pętla market-makingowa, która anuluje i ponownie wystawia oferty, wydaje zatem z obu budżetów jednocześnie, a anulowania są stroną, która po cichu drenuje pulę IP.

Autorytatywne liczby nie znajdują się nigdzie w tekście. WEEX publikuje je w tablicy rateLimits zwracanej przez exchangeInfo — /capi/v3/market/exchangeInfo pod adresem https://api-contract.weex.com dla futures oraz /api/v3/exchangeInfo dla spot. Odczytuj tę tablicę przy starcie zamiast kodować stałe na sztywno.

Liczby na żywo i dlaczego dokumentacja pokazuje inne

Oto odpowiedź rateLimits dla futures na żywo, pobrana 27 lipca 2026 r., obok przykładowych wartości wydrukowanych na stronie dokumentacji exchangeInfo WEEX:

To nie są małe różnice — przykład sugeruje około 200 wagi na sekundę, odpowiedź na żywo pozwala na około 0,83. Wartości w dokumentacji to przykłady odpowiedzi zastępczych, a nie opublikowany przydział, i każdy, kto zeskrapował stronę dokumentacji, aby określić swój budżet zapytań, zbudował rozwiązanie oparte na liczbie, która różni się o ponad dwa rzędy wielkości. To najsilniejszy argument za odczytywaniem exchangeInfo w czasie wykonywania: WEEX może zmieniać te wartości i robi to, a tylko endpoint mówi prawdę.

Przeanalizuj liczby dla futures na żywo, a praktyczny sufit okaże się niewygodny:

• 500 wagi ÷ 600 sekund = jedno zapytanie o wadze-1 co 1,2 sekundy w sposób ciągły, na IP.
• Polling endpointu o wadze-1 raz na sekundę — domyślne ustawienie w większości botów z samouczków — spala 600 wagi na 10 minut i przekracza limit przed jedenastą minutą.
• 300 zleceń na minutę = 5 zleceń na sekundę w sposób ciągły, na konto.

Budżet zleceń jest hojny. Budżet wagi IP nie jest. Jeśli Twoja architektura zakłada polling REST dla danych rynkowych, to założenie jest tym, co psuje wszystko.

Jak czytać nagłówki limitów szybkości WEEX

WEEX tworzy nazwy nagłówków na podstawie interwału, używając S, M, H, D dla sekundy, minuty, godziny i dnia. Zatem X-USED-WEIGHT-1M to waga zużyta przez Twoje IP w bieżącym oknie minutowym, a X-ORDER-COUNT-10S to zlecenia złożone przez Twoje konto w bieżącym oknie dziesięciosekundowym.

Parsuj X-REMAINING-* w każdej odpowiedzi i stosuj throttling na tej podstawie. Czekanie na 429, aby dowiedzieć się, że byłeś za szybki, to projekt, który gwarantuje, że będziesz za szybki — a WEEX wyraźnie zaznacza, że po 429 jesteś odpowiedzialny za zatrzymanie się, a nie ponawianie prób. Zauważ również, że ścieżka zleceń futures raportuje zarówno 10-sekundowy, jak i 1-minutowy licznik zleceń, więc seria, która czyści limit minutowy, może nadal wyzwolić krótsze okno.

Warto wiedzieć przed debugowaniem niewłaściwej rzeczy: kilka błędów wygląda jak throttling, ale nimi nie jest. Lista kodów błędów API WEEX oddziela 429 (przekroczono częstotliwość zapytań) od 40008 (wygasł znacznik czasu zapytania — podpis jest ważny przez 30 sekund) i 40018 (nielegalne zapytanie IP, co oznacza, że Twoje IP wywołujące nie znajduje się na białej liście klucza). Zegar przesunięty o ponad 30 sekund produkuje stały strumień odrzuceń, który zaskakująco często jest błędnie interpretowany jako problem z limitem szybkości.

Co się dzieje, gdy trafisz na 429 w API WEEX

Zapytanie kończy się niepowodzeniem ze statusem HTTP 429, a kontynuowane zapytania skutkują banem na 10s. Strona ograniczeń dostępu WEEX jasno określa obowiązek: po otrzymaniu 429 musisz przestać wysyłać zapytania i nie nadużywać API.

Dziesięć sekund brzmi jak czas, który da się przeżyć. W praktyce to najgorsze dziesięć sekund, jakie będziesz mieć, ponieważ limity szybkości są osiągane podczas zmienności — w tym samym momencie, w którym trzeba zabezpieczyć pozycję lub przesunąć stop. Prawidłową postawą jest token bucket po stronie klienta, zwymiarowany na podstawie wartości exchangeInfo na żywo z około 20% marginesem, plus wykładnicze wycofywanie się przy każdym 429, które się prześlizgnie. Ponawianie próby natychmiast zmienia 10-sekundowy ban w ban ciągły.

Budowanie bota, który mieści się w limitach API WEEX

Rozwiązaniem dla ciasnego budżetu wagi IP jest architektura, a nie taktyka: przestań robić polling dla wszystkiego, co może dostarczyć strumień.

WebSocket spot WEEX działa na wss://ws-spot.weex.com/v3/ws/public i wss://ws-spot.weex.com/v3/ws/private, z własnymi oddzielnymi limitami — 300 zapytań o połączenie na IP na 5 minut, maksymalnie 100 jednoczesnych połączeń na IP, 100 kanałów na połączenie i 240 operacji subskrypcji na godzinę na połączenie. To daje 10 000 slotów kanałów na IP, co jest większą ilością danych rynkowych, niż potrzebuje prawie każda strategia, a nic z tego nie dotyka Twojej wagi REST.

Zasada heartbeat ma tu znaczenie. Serwer wysyła ping i oczekuje PONG; połączenia, które nie odpowiedzą więcej niż 10 razy, są zrywane. Klient, który łączy się ponownie tylko przy zamknięciu socketu, a nigdy przy pominiętych pongach, utknie na martwym strumieniu, podczas gdy jego logika będzie po cichu handlować nieaktualnymi cenami.

Praktyczna konfiguracja w WEEX wygląda tak:

1. Utwórz klucz API w sekcji Konto → Zarządzanie API i powiąż białą listę IP. Niepowiązane klucze są najczęstszą przyczyną, dla której skompromitowane konto przetrwa wystarczająco długo, by mieć znaczenie.
2. Wywołaj exchangeInfo przy starcie, odczytaj rateLimits i zwymiaruj swój token bucket na podstawie odpowiedzi — nigdy na podstawie stałej w pliku konfiguracyjnym.
3. Przenieś wszystkie dane rynkowe do WebSocket. Zarezerwuj REST dla stanu konta, składania zleceń i uzgadniania.
4. Rozdziel oba budżety w kodzie. Jeden ogranicznik dla wagi IP (w tym anulowania i zapytania), drugi dla liczby zleceń. Jeden wspólny ogranicznik albo niepotrzebnie zdławi Twój przepływ zleceń, albo przekroczy Twoją wagę.
5. Używaj endpointów zleceń seryjnych, gdzie pozwala na to strategia. Nadal liczą się do ORDERS, ale redukują liczbę podróży w obie strony i opóźnienia.
6. Uzgadniaj na timerze, nie przy każdej realizacji. Zapytania o pozycję i saldo to endpointy o wadze-1, które szybko się sumują, gdy są wyzwalane przy każdym zdarzeniu.

Jeśli nadal decydujesz, czy podejście oparte na API w ogóle pasuje, przegląd WEEX dotyczący wsparcia handlu przez API obejmuje decyzję REST kontra WebSocket, zanim zaangażujesz się w architekturę.

Co jest najważniejsze

Ze wszystkiego powyżej, jedna liczba rządzi projektem: przydział wagi IP dla futures na żywo wynoszący 500 na 10 minut. Jest on na tyle restrykcyjny, że każda pętla danych rynkowych oparta na pollingu REST jest zdyskwalifikowana, co oznacza, że zasady limitów szybkości API WEEX nie są tak naprawdę problemem z throttlingiem, który trzeba dostroić — są sygnałem, że platforma oczekuje klientów strumieniowych. Buduj w ten sposób od samego początku, a 429 przestaną być tematem.

Zweryfikuj każdą liczbę tutaj względem exchangeInfo, zanim przejdziesz na żywo. Limity to parametry operacyjne, a giełdy zmieniają je bez większego powiadomienia.

FAQ

1. Jaki jest limit szybkości API WEEX?

WEEX egzekwuje dwa limity: budżet REQUEST_WEIGHT na adres IP obejmujący wszystkie endpointy z wyjątkiem składania zleceń oraz budżet ORDERS na konto obejmujący składanie zleceń pojedynczych i seryjnych. Na dzień 27 lipca 2026 r. endpoint exchangeInfo dla futures na żywo zwraca 500 wagi na 10 minut i 300 zleceń na minutę. Odczytuj endpoint zamiast ufać jakiejkolwiek opublikowanej liczbie, w tym tej.

2. Czy limit szybkości API WEEX jest na IP, czy na klucz API?

Na IP dla ważonych endpointów — WEEX stwierdza, że limity te opierają się na IP, a nie na kluczu API lub UID. Składanie zleceń jest wyjątkiem: jest ograniczone na konto (userId). Uruchamianie kilku kluczy z jednego serwera nie mnoży Twojego przydziału wagi.

3. Co oznacza HTTP 429 w WEEX i jak długi jest ban?

429 oznacza, że Twoja częstotliwość zapytań przekroczyła limit. WEEX stosuje 10-sekundowy ban i oczekuje, że przestaniesz wysyłać zapytania, zamiast ponawiać próbę natychmiast.

4. Czy zapytania o anulowanie zlecenia liczą się do limitu szybkości zleceń?

Nie. Tylko składanie zleceń pojedynczych i seryjnych podlega limitowi ORDERS. Anulowanie i sprawdzanie zleceń jest ograniczone przez wagę IP, dlatego strategie intensywnie anulujące najpierw wyczerpują budżet IP.

5. Jak sprawdzić pozostały limit API WEEX?

Odczytaj nagłówki odpowiedzi. X-REMAINING-WEIGHT-1M pokazuje wagę IP pozostałą w bieżącej minucie, a X-ORDER-REMAINING-10S i X-ORDER-REMAINING-1M pokazują pozostałą pojemność zleceń dla Twojego konta.

6. Jakie są limity WebSocket WEEX?

300 zapytań o połączenie na IP na 5 minut, do 100 jednoczesnych połączeń na IP, maksymalnie 100 kanałów na połączenie i 240 operacji subskrypcji na godzinę na połączenie. Pomiń więcej niż 10 pingów serwera, a połączenie zostanie zamknięte.

7. Dlaczego moje zapytanie API WEEX kończy się niepowodzeniem nawet przy niskim wolumenie?

Sprawdź błąd 40008 przed założeniem throttlingu. Podpisane zapytania są ważne przez 30 sekund, więc zegar serwera przesunięty o ponad 30 sekund względem czasu giełdy produkuje stałe odrzucenia, które przypominają problem z limitem szybkości. Błąd 40018 wskazuje na niedopasowanie białej listy IP.

Ostrzeżenie o ryzyku

Aktywa kryptograficzne są zmienne, a handel sterowany przez API może prowadzić do częściowej lub całkowitej utraty środków. Zautomatyzowane systemy potęgują tę ekspozycję: klient z ograniczoną szybkością lub rozłączony może nie złożyć stopa, nie anulować nieaktualnej oferty lub nie zamknąć pozycji lewarowanej, podczas gdy rynek porusza się przeciwko niemu, a 10-sekundowy ban podczas skoku zmienności wystarczy, by zamienić zarządzalną stratę w likwidację. Pozycje futures niosą ryzyko dźwigni finansowej i mogą zostać w pełni zlikwidowane. Klucze API niosą ryzyko powiernicze i operacyjne — klucz bez białej listy lub z nadmiernymi uprawnieniami może zostać użyty do opróżnienia lub nadużycia konta, więc ogranicz uprawnienia, powiąż białą listę IP i nigdy nie przyznawaj praw do wypłaty botowi handlowemu. Limity szybkości, wagi endpointów i parametry kontraktów mogą ulec zmianie bez powiadomienia; zweryfikuj je względem endpointów na żywo przed zainwestowaniem kapitału. Nic tutaj nie jest poradą inwestycyjną.