Acasă
» Cunoştinţe
»
Cum să rezolvi erorile de conectare la cheia API pentru roboții de tranzacționare cripto
Cum să rezolvi erorile de conectare la cheia API pentru roboții de tranzacționare cripto
Când un bot de tranzacționare cripto nu se poate conecta la Binance sau OKX, mesajul poate fi de genul „autentificare eșuată” sau „cheie API invalidă”. Acest mesaj nu înseamnă neapărat că cheia în sine este greșită. Eroarea poate proveni din permisiuni, o listă de adrese IP permise, un punct final de produs nepotrivit, o semnătură incorectă, un ceas nesincronizat sau o limită a ratei de solicitări.
Acest ghid folosește un fir de discuție evident ipotetic ca exemplu de funcționare. Doar un exemplu ilustrativ - nu un test, un rezultat sau o mărturie reală: Maya a creat un bot de tranzacționare spot și primește o eroare de conexiune după ce introduce datele de autentificare dintr-un cont de schimb. Procesul de depanare de mai jos arată cum ar putea izola cauza fără a-și expune secretul sau a acorda acces inutil la cont. Interfața dvs. de schimb, furnizorul botului și formularea erorii pot diferi.
Ce ar trebui să faci înainte de a schimba cheia API?
Întrerupeți botul și împiedicați reîncercările automate în timp ce investigați. Solicitările eșuate repetate pot face mai greu de distins o problemă separată de limită de rată de o problemă de autentificare. Salvați textul exact al erorii, starea HTTP, numele exchange-ului, tipul de produs, endpoint-ul dacă botul le afișează și ora erorii. Nu inserați niciodată un secret API, o parolă, o solicitare semnată sau un antet de autorizare completă într-o problemă publică, un chat, o captură de ecran sau un tichet de asistență.
O cheie API identifică integrarea. Secretul API este valoarea privată utilizată pentru semnarea cererilor, iar o frază de acces API este o acreditare suplimentară cerută de unele exchange-uri, inclusiv OKX. Tratați-le pe toate ca fiind sensibile. Dacă un secret a fost expus, revocați cheia respectivă și creați un înlocuitor prin interfața contului oficial al exchange-ului înainte de a continua.
Machetă ilustrativă a interfeței utilizator: formularul de conexiune bot separă câmpurile exchange, API key, API secret și passphrase înainte de un test de conexiune.
Cărei familii de erori îi aparține mesajul?
Începeți cu clasificarea, mai degrabă decât cu editări aleatorii. Erorile de autentificare și autorizare indică de obicei acreditări, permisiuni, restricții IP sau semnare. Erorile de timp indică ceasul mașinii sau marcajul temporal al solicitării. Erorile de rețea și de limită de rată necesită un răspuns diferit: verificați accesibilitatea, încetiniți solicitările și confirmați dacă o comandă anterioară a fost acceptată înainte de a reîncerca.
Semnal observat
Zona probabilă
Prima verificare
Binance-2015 REJECTED_MBX_KEY
Nepotrivire de cheie, IP sau permisiune
Starea cheii, IP-ul permis și permisiunea necesară
Binance-1022 INVALID_SIGNATURE
Semnarea sarcinii utile sau a secretului
Parametri exacți, codificare, metodă și secret de semnare
Binance-1021 INVALID_TIMESTAMP
Ceas sau fereastră de recepție
Sincronizare UTC și generare de timestamp-uri
Binance -1003 TOO_MANY_REQUESTSsau OKX50011
Volumul solicitărilor
Interval de interogare, reîncercări și limite specifice punctului final
Eroare de timp OKX50102
Marcajul temporal diferă de ora serverului
Ora UTC și punctul final al orei de schimb
Aceste coduri și mesaje sunt referințe documentate, nu garanții că fiecare bot le va afișa neschimbate. Un bot terț poate traduce, scurta sau încapsula răspunsul exchange.
Cum verifici starea și permisiunile cheii API?
Deschideți pagina de administrare API a exchange-ului direct de pe site-ul oficial sau din aplicație. Confirmați că cheia este activă, aparține contului sau subcontului dorit și este destinată produsului pe care îl va utiliza botul. O cheie creată pentru un mediu sau un cont poate să nu funcționeze pentru altul.
Folosește privilegiile minime. Un bot care citește doar soldurile are nevoie de acces de citire. Un bot care plasează și anulează ordine spot are nevoie de permisiunea de tranzacționare a bursei. Retragerile sunt o capacitate separată și ar trebui să rămână dezactivate, cu excepția cazului în care există un motiv specific, înțeles, pentru a le activa. O conexiune reușită nu dovedește că botul poate plasa ordine, iar o eroare de permisiune în timpul unui test de comandă nu înseamnă automat că acreditările sunt nevalide.
Machetă ilustrativă a interfeței utilizator: verificați permisiunile minime necesare pentru bot și mențineți retragerile dezactivate în timpul depanării.
În exemplul ipotetic, Maya verifică mai întâi dacă botul ei este configurat pentru tranzacționare spot, în timp ce cheia a fost creată doar cu acces de citire. Ea înregistrează permisiunea necesară din documentația botului, activează doar acea permisiune, dacă este cazul, salvează modificarea și așteaptă ca bursa să o aplice. Ea nu activează retragerile doar pentru a trece testul de conexiune.
Ar putea o listă albă de IP-uri să blocheze botul?
O listă albă de IP-uri, numită și listă de IP-uri permise, restricționează utilizarea API-ului la adresele sursă aprobate. Aceasta îmbunătățește securitatea, dar poate bloca o cheie perfect validă atunci când botul rulează de pe un server cloud, un container, o conexiune de domiciliu sau un furnizor al cărui IP de ieșire s-a modificat. Solicitați furnizorului botului adresa sau adresele IP de ieșire exacte. Nu ghiciți pe baza IP-ului public al laptopului dacă botul rulează de fapt în altă parte.
Comparați adresa afișată de furnizor cu lista de acces permisă a exchange-ului. Verificați IPv4 versus IPv6, spațiile sau intrările învechite și dacă cheia este legată de contul corect. Dacă furnizorul utilizează un interval de adrese rotativ, întrebați dacă oferă o adresă IP de ieșire stabilă. Nu dezactivați permanent lista de acces permisă ca o soluție rapidă; dacă o eliminați temporar pentru o diagnosticare controlată, restaurați-o imediat și rotiți cheia dacă modificarea a expus o integrare sensibilă.
Machetă ilustrativă a interfeței utilizator: lista de acces permis trebuie să conțină adresa IP sursă aprobată de serverul bot înainte ca solicitările autentificate să poată fi procesate.
Cheia, secretul și parola provin din aceeași integrare?
Copiați din nou datele de autentificare fără a adăuga spații, ghilimele, sfârșituri de linie sau caractere ascunse. Confirmați că cheia API și secretul au fost generate ca o singură pereche. Pe OKX, confirmați și fraza de acces exactă introdusă la crearea cheii. Fraza de acces nu este același lucru cu parola de conectare la cont, iar exchange-ul precizează că o frază de acces pierdută nu poate fi recuperată; este necesar un nou set de chei.
Verificați bursa selectată în bot. O cheie Binance nu poate autentifica o solicitare OKX, iar o cheie dintr-un cont principal poate să nu reprezinte subcontul pe care intenționați să îl tranzacționați. Dacă nu sunteți sigur ce valoare a fost inserată în ce câmp, revocați cheia incertă și creați o pereche nouă, în loc să testați în mod repetat o credențială necunoscută.
Machetă ilustrativă a interfeței utilizator: această formulare generală a erorii necesită verificări separate pentru cheie, adresa IP sursă și permisiuni.
Cum se produc erorile de semnătură și de marcaj temporal?
Cererile API private nu sunt autentificate prin trimiterea secretului în text simplu. Clientul construiește o sarcină utilă de semnare precisă și produce o semnătură. O singură nepotrivire - cum ar fi o ordine modificată a parametrilor, o diferență de codificare URL, o metodă HTTP greșită, un secret greșit sau un corp modificat al cererii - o poate invalida.
Pentru cererile REST Binance Spot, documentația oficială descrie semnarea HMAC-SHA-256 pentru cheile HMAC și necesită o marcă temporală pentru cererile semnate. Documentația explică, de asemenea recvWindow, fereastra de temporizare permisă. Referința actuală prezintă o valoare exemplu de cinci secunde, dar setările și limitele de schimb ale unui bot pot varia; utilizați valoarea acceptată de endpoint și evitați mascarea unei probleme de ceas cu o fereastră inutil de mare.
Cererile REST private OKX utilizează anteturi precum OK-ACCESS-KEY, OK-ACCESS-SIGN, OK-ACCESS-TIMESTAMP, și OK-ACCESS-PASSPHRASE. OKX descrie o pre-hash realizată din timestamp, metoda HTTP, calea cererii și corp, urmată de codificare HMAC-SHA-256 și Base64. De asemenea, specifică ora UTC ISO 8601 cu precizie de milisecunde și recomandă sincronizarea în funcție de punctul final de timp public. Asigurați-vă că ceasul botului, metoda HTTP, calea, parametrii interogării și corpul corespund cu ceea ce semnează.
Machetă ilustrativă a interfeței utilizator: diagnosticarea semnăturilor ar trebui să expună verificările de stare și de timp fără a dezvălui secretul în sine.
În firul ipotetic al Mayei, botul înregistrează o semnătură nevalidă în loc de o permisiune respinsă. Ea compară metoda de semnare documentată a furnizorului botului cu exchange-ul selectat, verifică dacă secretul nu a fost trunchiat, sincronizează ceasul serverului cu UTC și testează un endpoint de citire autentificată inofensiv. Dacă furnizorul controlează intern semnarea, ea furnizează doar acreditările de înlocuire prin câmpul său de secret protejat și solicită furnizorului să inspecteze jurnalele redactate.
Botul folosește mediul și endpoint-ul produsului corecte?
Separați mediile de „producție” sau mainnet de mediile de „testnet” sau demo. O cheie creată pentru unul poate să nu se autentifice față de celălalt. De asemenea, distingeți punctele finale ale contractelor spot, margin, futures și opțiuni. Aceeași pereche de monede poate avea simboluri, permisiuni, moduri de cont și reguli de comandă diferite pentru diferite produse.
Citește ghidul de integrare al botului pe platforma de schimb și compară adresa URL de bază, selectorul de produs, tipul de cont, formatul simbolului și modul WebSocket sau REST cu documentația actuală a platformei de schimb. Dacă botul oferă integrări separate cu Binance Spot și Futures, alege-o pe cea care corespunde cheii și strategiei. Nu trece niciodată la un endpoint live doar pentru că o acreditări de testnet a eșuat.
Machetă ilustrativă a interfeței utilizator: producție versus testnet și spot versus futures trebuie să corespundă atât cheii API, cât și integrării botului.
Este posibil ca conexiunea să eșueze din cauza limitelor de rată sau a rețelei?
După ce datele de autentificare sunt corecte, inspectați modelul de solicitare. Un bot care verifică soldurile, deschide comenzi și analizează datele de piață prea frecvent poate atinge limitele chiar și atunci când fiecare semnătură este validă. Binance documentează -1003 TOO_MANY_REQUESTSși recomandă utilizarea fluxurilor WebSocket pentru actualizări live, acolo unde este cazul. OKX documentează 50011o limită de rată atinsă și notează că limitele variază în funcție de endpoint și pot fi bazate pe IP sau ID-ul utilizatorului.
Reduceți sondajele duplicate, adăugați o perioadă de așteptare exponențială, limitați reîncercările și evitați pornirea mai multor instanțe de bot cu aceeași integrare. O expirare nu este o dovadă că o comandă a eșuat: verificați starea comenzii înainte de a trimite o comandă duplicată. Verificați, de asemenea, DNS, regulile firewall, accesul HTTPS de ieșire, setările proxy, interceptarea TLS și dacă endpoint-ul exchange este disponibil în regiunea dvs. sau pentru contul dvs.
Machetă ilustrativă a interfeței utilizator: avertismentele privind fereastra de timp și limita de rată necesită remedieri diferite, chiar și atunci când apar în aceeași vizualizare de diagnosticare.
Care este cea mai sigură metodă de a retesta după o reparație?
Salvați exact modificarea pe care ați făcut-o, cum ar fi corectarea listei de adrese IP permise sau selectarea opțiunii Spot.
Folosește mai întâi o solicitare autentificată doar pentru citire, cum ar fi verificarea informațiilor despre cont sau a soldurilor.
Confirmă că botul raportează contul și produsul vizate, fără a afișa secrete.
Dacă este necesar un test de comandă, utilizați cea mai mică dimensiune practică și o piață controlată numai după ce ați înțeles consecințele, comisioanele și modul de cont.
Verificați jurnalele pentru coduri de stare redactate, marcaje temporale, nume de puncte finale și număr de reîncercări.
Opriți și rotiți cheia dacă eroarea persistă după verificarea elementelor de bază sau dacă este posibil ca cheia să fi fost copiată într-un serviciu neîncrezător.
Machetă ilustrativă a interfeței utilizator: o retestare controlată separă accesul la citire și tranzacționarea spot de accesul la contracte futures netestate, în timp ce retragerile rămân dezactivate.
Ce greșeli ar trebui să eviți?
Nu publicați și nu trimiteți prin e-mail secretul API, nici măcar atunci când solicitați ajutor pentru depanare.
Nu activați retragerile ca o scurtătură în caz de eșec de autentificare.
Nu adăugați un interval IP larg sau necunoscut la o listă de acces permis doar pentru a opri o eroare.
Nu reîncercați o comandă incertă orbește după o expirare; verificați mai întâi starea acesteia.
Nu presupuneți că o cheie este validă pentru fiecare produs, subcont, regiune sau mediu de schimb.
Nu creșteți frecvența de interogare în timp ce investigați o eroare.
Nu vă bazați mai mult pe o captură de ecran veche a unei pagini de setări Exchange decât pe documentația oficială actuală.
Acest articol a fost pregătit pe baza referințelor oficiale disponibile la 16 septembrie 2026. Acesta explică o metodă de diagnosticare, nu o garanție că un anumit bot, cont de exchange, jurisdicție sau versiune API va funcționa. Dacă exchange-ul afișează un mesaj de securitate, conformitate, blocare a contului sau disponibilitate a produsului, urmați procesul oficial de asistență al exchange-ului și nu încercați să ocoliți restricția.