שגיאות API נפוצות ב-OKX ורשימת אבחון: תקן לפי הטבלה הזו

מי שכותב סקריפטים אלגוריתמיים, בתשעה מתוך עשרה מקרים לא נתקע באסטרטגיה אלא בשורת שגיאה אדומה: הסקריפט רץ, הטרמינל מקפיץ שרשרת של code ואנגלית שלא מובנים, ובן אדם נתקע. החדשות הטובות: לשגיאות ה-API של OKX יש רק כמה דגמים תכופים, וברגע שמבינים איך כל אחת נראית ולאיזו סיבה היא מתאימה, האבחון הופך הרבה יותר מהיר.

במאמר הזה אנחנו (צוות המערכת של MeowQuant) ריכזנו את השגיאות שנתקלנו בהן בעצמנו, ושראינו שוב ושוב בקהילות, לרשימה אחת — שליבה היא טבלת קודי שגיאה. כשמשהו משתבש, קודם אתר בטבלה לפי קוד השגיאה או מילת מפתח, ואז הסתכל על האבחון המתאים שלמטה. בסוף הקריאה אתה אמור לפתור את רוב השגיאות בעצמך תוך דקות, ולא לבהות באדום בחוסר אונים.

קודם תלמד לקרוא את השגיאה: code + msg

הצעד הראשון בפתרון תקלות הוא להבין את השגיאה עצמה. כשממשק של OKX נכשל הוא מחזיר שלושה דברים:

• קוד סטטוס HTTP: השכבה הגסה ביותר, למשל 401 (בעיית אימות), 429 (יותר מדי בקשות), 400 (הבעיה בבקשה עצמה).
• code: קוד שגיאה מספרי של OKX עצמה, שמצביע בדיוק הרב ביותר על סוג הבעיה. זה הבסיס העיקרי לאבחון שלך.
• msg: הסבר מילולי שעוזר לאשר את הכיוון, ולפעמים מצביע ישירות על השדה שנכשל.

אם אתה משתמש ב-ccxt, היא עוטפת את השגיאות הגולמיות האלה לסוגי חריגות קריאים יותר: בעיית אימות זורקת AuthenticationError, מגבלת קצב זורקת RateLimitExceeded, וחוסר יתרה זורק InsufficientFunds. מידע החריגה נושא בדרך כלל גם את ה-code וה-msg המקוריים של OKX. הרגל טוב הוא להדפיס אותם בבירור עם try/except:

import ccxt

okx = ccxt.okx({
    'apiKey':   'ה_apiKey_שלך',
    'secret':   'ה_secret_שלך',
    'password': 'ה_Passphrase_שלך',
    'enableRateLimit': True,
})

try:
    balance = okx.fetch_balance()
    print('USDT זמין:', balance['USDT']['free'])
except ccxt.InvalidNonce as e:
    print('פג תוקף חותמת הזמן (50102), תקן את השעון ונסה שוב:', e)
except ccxt.AuthenticationError as e:
    print('כשל אימות, קודם הסתכל על ה-code בשגיאה ורק אז החלט מה לבדוק:', e)
except ccxt.RateLimitExceeded as e:
    print('הגעת למגבלת קצב, האט את הבקשות:', e)
except ccxt.BaseError as e:
    print('שגיאה אחרת, בדוק את ה-code/msg המקוריים:', e)

רשום לעצמך את שרשרת ה-code וה-msg מהחריגה כמו שהיא, השווה לטבלה שלמטה, וברוב המקרים תאתר לאיזו קטגוריית בעיה זה שייך.

טבלת השגיאות התכופות

הטבלה הבאה מכסה את השגיאות שמתחילים נתקלים בהן הכי הרבה. משמעויות קודי השגיאה שבטבלה אומתו בספטמבר 2026 מול פרק ה-Error Code בתיעוד OKX API v5 (OKX משנה מדי פעם ערכי קוד, ואם לא תואם — לך לפי טקסט ה-msg והתיעוד הרשמי), והעיקר הוא להתאים בין "סיבה ← איך לתקן". בקטגוריית האימות במיוחד צריך להסתעף לפי ה-code: שתי השגיאות נראות כמו "אי אפשר להתחבר", אבל 50113 ו-50105 שולחות אותך לבדוק דברים שונים לגמרי.

אבחון ותיקון, שורה אחר שורה

הטבלה נותנת כיוון, הסעיף הזה נותן פרטים. בחר את השורה שנתקלת בה וקרא הלאה.

אימות (50102 / 50105 / 50110 / 50111 / 50112 / 50113) והרשאות (50120)

ברמת ה-HTTP כל כשלי האימות הם 401, וב-ccxt רובם זורקים AuthenticationError (גם PermissionDenied ש-50110 זורק הוא תת-מחלקה שלו). החריג הוא 50102, חותמת זמן שפג תוקפה: לפי קוד המקור של הענף הראשי של ccxt נכון ל-2026-09 הוא ממופה ל-InvalidNonce, ששייך לענף NetworkError, כך ש-except AuthenticationError לבדו לא יתפוס אותו וצריך ענף נפרד. ולכן אל תעבור על "הסיבות הנפוצות" אחת-אחת — קודם שלוף את ה-code, ואז לך לפי השורה שמתאימה לו. 50120 «אין הרשאה» צריך להוציא בנפרד: הוא לא שייך לערימת ה-401. לפי טבלת קודי השגיאה הרשמית הוא חוזר עם HTTP 200 ומזוהה לפי ה-code שבגוף התשובה, כלומר ברמת הפרוטוקול הבקשה «הצליחה» — ולפי קוד הסטטוס לבדו אתה בכלל לא רואה שמשהו השתבש.

• 50113 Invalid signature: הסתכל על שלב החתימה. איך מורכב טקסט החתימה (שיטת הבקשה, נתיב הבקשה, גוף הבקשה), אם המפתח ל-HMAC הוא באמת ה-secret, ואם בוצע HMAC-SHA256 ואז Base64. אם אתה עובד עם ccxt, החתימה נעשית על ידי הספרייה — ואז חשוד קודם כל ב-secret שהועתק שגוי.
• 50105 Passphrase שגוי (50104 = לא מולא כלל): בדוק רק את הסיסמה. השדה password ב-ccxt חייב להיות מולא עם ה-Passphrase שהגדרת בעת יצירת המפתח — לא סיסמת ההתחברות, וגם לא ה-secret; אם אינך זוכר אותו, הדרך היחידה היא למחוק את המפתח וליצור מחדש.
• 50102 / 50112 בעיית חותמת זמן: בדוק רק את השעון. לפי התיעוד הרשמי, פער של יותר מ-30 שניות בין חותמת הזמן של הבקשה לזמן השרת גורם לדחייה. הדלק כוונון אוטומטי ב-NTP, ובמכונות שרצות לאורך זמן ודא מדי פעם שהסנכרון באמת עובד. ב-ccxt קוד 50102 זורק InvalidNonce: בענף הזה תקן את השעון ונסה שוב, ובסוף השאר תופס כללי של BaseError.
• 50111 Invalid OK-ACCESS-KEY: בדוק את ה-apiKey עצמו — רווח בתחילה או בסוף אחרי הדבקה, תו חסר, מפתח שנמחק, או מפתח אמיתי שחובר לדמו (ולהפך).
• 50110 IP מחוץ לרשימה: בדוק את יציאת הרשת, לא את האישורים. ראה את הפרק "רשימת IP מורשים" למטה.
• 50120 אין הרשאה (HTTP 200): כל האישורים תקינים, פשוט למפתח הזה לא סומנה ההרשאה המתאימה. הוא לעולם לא מופיע בתור 401 — הדרך היחידה לראות אותו היא לקרוא את ה-code שבגוף התשובה, ולכן אל תכתוב את הטיפול רק בתור if status == 401. ראה "אין הרשאה" למטה.

ודרך אגב: טקסט ה-msg של OKX נוקב לפעמים ישירות בכותרת שבה הבעיה — רשום אותו כמו שהוא לצד ה-code, וזה מהיר בהרבה מניחוש לפי תחושה.

אין הרשאה

הסימפטום הטיפוסי הוא "אפשר לבדוק יתרה, אי אפשר להזין". בדיקת יתרה עוברת בהרשאת קריאה, הזמנה עוברת בהרשאת מסחר, ושתיהן מאושרות בנפרד. חזור לניהול ה-API בלוח של OKX, מצא את המפתח הזה והוסף לו 'מסחר', בלי צורך ביצירה מחדש. אם מתוך הרגל סימנת גם משיכה — אל תשאיר אותה; למפתח שמריץ אלגו לעולם אל תפתח הרשאת משיכה. ואל תבין את "הרשאת המסחר" בצמצום: לפי ההגדרה בתיעוד של OKX היא כוללת, מעבר להזמנה וביטול, גם העברת כספים וחלק מהגדרות החשבון — כך שאין שום צורך לסמן משיכה רק כדי להעביר כספים בין החשבונות שלך.

רשימת IP מורשים (50110)

השגיאה הזו אומרת "כתובת ה-IP היוצאת שאתה עליה כרגע אינה ברשימה של המפתח הזה", ולכן האבחון מתחיל ביציאת הרשת ולא באישורים:

• קודם ברר מהי כתובת ה-IP היוצאת הנוכחית שלך והשווה אותה לרשימה שמילאת למפתח הזה בלוח. שים לב שמדובר בכתובת היוצאת: עם proxy פעיל, דרך שער תאגידי, או אחרי חיוג מחדש של האינטרנט הביתי — היציאה עשויה בהחלט לא להיות זו שאתה חושב.
• אם כתובת היציאה לא יציבה, כיוון הפתרון הוא לקבע את היציאה ולא להסיר את המנעול: העבר את האסטרטגיה למכונה עם IP קבוע, או עדכן את הרשימה בקצב מבוקר כשהיציאה באמת משתנה. ב-OKX אפשר לקשור לכל מפתח עד 20 כתובות IP, כולל IPv4/IPv6 וטווחי רשת, כך שלא קשה להשאיר מרווח.
• בשלב הדיבאג השתמש במפתח לקריאה בלבד או במפתח דמו, ולא בניסויים חוזרים עם המפתח הראשי שיש לו הרשאת מסחר.
• אל תהפוך את "ביטול הרשימה" לפעולת אבחון שגרתית. רשמית, קישור IP הוא המלצה חמה ולא חובה; אבל יש כלל שכדאי לזכור: מפתח בלי IP מקושר, שיש לו הרשאת trade או withdraw, פג תוקף אחרי 14 ימים ללא פעילות — כלומר מפתח לא מקושר הוא לא רק מסוכן יותר, הוא גם עלול יום אחד פשוט להפסיק לעבוד. על מפתחות דמו כלל פקיעת התוקף הזה לא חל, וזו עוד סיבה לעשות איתם את הדיבאג.

יתרה לא מספיקה

מעבר למשמעות המילולית של כסף לא מספיק, יש סיבה נסתרת נוספת: ל-OKX יש חשבונות שונים (חשבון מימון, חשבון מסחר ועוד), והכסף שלך אולי לא נמצא בחשבון שמשמש להזמנה. ודא שהכסף כבר הועבר לחשבון המסחר. בדמו, אם נגמר הכסף הווירטואלי אפשר לאפס אותו בממשק הדמו — וזה גם היתרון של תרגול קודם בדמו, ניסוי וטעייה בלי כסף אמיתי.

symbol / דיוק

צמד ספוט ב-ccxt הוא באופן אחיד אותיות גדולות/אותיות גדולות עם קו נטוי קדמי, למשל BTC/USDT. כתיבה כ-BTCUSDT, אותיות קטנות, או פורמט חוזים — כולן יחזירו שגיאה. אם הכמות קטנה מדי או הדיוק שגוי, השתמש ב-load_markets() כדי לבדוק את הכמות המינימלית והדיוק של הצמד הזה, ומלא לפי הנדרש. יש לנו דוגמת הזמנה מלאה במבוא המעשי ל-API.

מגבלת קצב ו-retry עם נסיגה

מגבלת קצב (50011 / Too Many Requests) היא הקטגוריה שמשתמשי סקריפט נתקלים בה הכי הרבה, ושהכי כדאי למנוע מראש. היא לא אומרת שעשית משהו לא בסדר, אלא שהבקשות צפופות מדי והפעילו את ההגנה של הבורסה. הטיפול בה בשתי שכבות:

שכבה ראשונה: הדלק את מגביל הקצב המובנה של ccxt. הוסף באתחול 'enableRateLimit': True, ו-ccxt תשתול אוטומטית מרווחים סבירים בין הבקשות. ברוב המקרים השלב הזה מספיק:

okx = ccxt.okx({
    'apiKey':   'ה_apiKey_שלך',
    'secret':   'ה_secret_שלך',
    'password': 'ה_Passphrase_שלך',
    'enableRateLimit': True,   # מגביל קצב אוטומטי, הדלק קודם
})

שכבה שנייה: הוסף retry עם נסיגה מעריכית. אם האסטרטגיה שלך באמת מבצעת בקשות צפופות ברגעים מסוימים (למשל סורקת הרבה צמדים בו-זמנית), מגביל הקצב האוטומטי לבדו עדיין עלול להיתקל מדי פעם. אז עטוף את הבקשות הקריטיות בשכבת retry: נתקלת פעם, חכה שנייה ונסה שוב; שוב, חכה 2 ואז 4 שניות, האריך בהדרגה, ואחרי מספיק כשלונות — ויתר עם שגיאה.

import ccxt, time

def with_retry(fn, max_tries=5):
    delay = 1
    for i in range(max_tries):
        try:
            return fn()
        except ccxt.RateLimitExceeded:
            print(f'מגבלת קצב, ניסיון {i+1}, מחכה {delay} שניות ומנסה שוב')
            time.sleep(delay)
            delay *= 2          # נסיגה מעריכית: 1 ← 2 ← 4 ← 8 ...
    raise RuntimeError('עדיין נתקל במגבלת קצב אחרי כמה ניסיונות, מוותר')

# שימוש: זרוק לתוכה את הקריאה שעלולה להיתקל במגבלת קצב
ticker = with_retry(lambda: okx.fetch_ticker('BTC/USDT'))
print(ticker['last'])

דוגמה שלילית: אל תכתוב while True: שמיד אחריו פוגע בממשק בלי שום השהיה בין לבין. לולאה כזו תזרוק עשרות עד מאות בקשות בשנייה אחת, תיתקל מיד במגבלת קצב, ובמקרים חמורים כל המפתח ייחסם זמנית. בכל לולאת תדירות גבוהה חייבים להשאיר מרווח.

מהמורה נפוצה

שאלות נפוצות

אחרי שעברת את משוכת איתור התקלות, הסקריפט שלך לא ייתקע בקלות. הדבר הבא ששווה להשקיע בו זמן הוא לכתוב ניהול סיכונים לתוך הקוד — מפחיד יותר משגיאה הוא סקריפט שלא מחזיר שגיאה אבל מזין הזמנות שגויות כל הזמן. ואל תשכח להריץ קוד חדש קודם בדמו, איתור תקלות בלי כסף אמיתי.