如何修復 Binance API 請求的身份驗證失敗問題？

API金鑰權限配置

1. 在瀏覽器網址列輸入www.binance.com直接存取幣安官網，切勿點選外部連結。

2. 透過使用者頭像下拉式選單導覽至API 管理並驗證該選項是否存在；它的缺失表示這是一個網路釣魚網站。

3. 確認目標 API 金鑰已啟用現貨交易和期貨交易切換。

4. 確保IP白名單處於活動狀態並且包含交易伺服器的準確出站IP位址；僅用於本機測試，請謹慎選擇「無 IP 限制」。

5. 交叉檢查程式碼中的憑證：執行print(exchange.requiredCredentials)以驗證apiKey 、 Secret和可選uid是否存在。

簽名生成協議

1. 在建立任何簽章請求之前，使用https://api.binance.com/api/v3/time檢索伺服器時間。

2. 精確地依照timestamp=1718234567890建構查詢字串 — 沒有多餘的空格，沒有等於或與符號的 URL 編碼。

3. 使用 UTF-8 編碼的金鑰和原始查詢字串計算 HMAC-SHA256 簽名，然後輸出不含前綴或後綴的十六進位摘要。

4. 將產生的簽章作為簽章參數（而不是標頭）傳遞，並在參數和查詢字串中包含時間戳記。

5. 將X-MBX-APIKEY標頭專門用於 API 金鑰值；切勿將其嵌入 URL 或正文中。

系統時間同步

1. 在 Linux 系統上執行timedatectl status以確認 NTP 服務處於作用中並已同步。

2.透過exchange.fetch_time()取得幣安伺服器時間並與本地紀元毫秒進行比較。

3. 如果偏差超過 5000 毫秒，請使用sudo chronyc makestep強制立即修正。

4. 使用'options': {'adjustForTimeDifference': True}初始化 CCXT 以啟用自動偏移補償。

5. 避免在即時交易期間手動調整時間－僅依靠 NTP 驅動的同步。

速率限制行為

1. 在交換實例化時設定enableRateLimit: True以啟動內建限制邏輯。

2. 每次呼叫後監視X-MBX-USED-WEIGHT-1M回應標頭，以追蹤每分鐘 1200 次上限的即時使用情況。

3. 當前分鐘視窗內體重消耗超過 1100 時插入動態睡眠間隔。

4. 將順序符號請求替換為批次端點（例如fetch_tickers([symbols])），以減少總呼叫計數。

5. 將空響應或延遲確認視為潛在的速率限制指標，而不僅僅是 HTTP 429 錯誤。

環境特定的憑證處理

1. 將 API 金鑰儲存在原始碼控制之外的外部creds.yml檔案中，遵循嚴格的縮排和間距規則。

2. 將creds.yml永久加入.gitignore以防止意外提交。

3. 使用驗證欄位存在性和類型完整性的專用載入器函數以程式設計方式載入憑證。

4. 切勿在 Python 腳本中對密鑰進行硬編碼（即使是為了調試），也不要將它們儲存在子進程可存取的環境變數中。

5.透過API管理介面立即輪換受損或過時的密鑰；舊密鑰一旦刪除就無法恢復。

常見問題解答

問題 1：即使使用正確的 API 金鑰和密碼，為什麼我的請求仍回傳代碼 -1022？由於時間戳記不符、格式錯誤的查詢字串或不正確的 HMAC 輸入順序，簽名驗證失敗 - 獨立驗證所有三個元件。

問題 2：我可以在多台伺服器上重複使用相同的 API 金鑰嗎？不可以。每個伺服器必須有自己的 IP 白名單金鑰；共用金鑰違反安全原則並觸發自動撤銷。

Q3：如果我不小心開啟了「提幣」權限會怎麼樣？ API金鑰獲得完整的資產轉移能力；任何妥協都會導致不可逆轉的資金損失——除非明確要求，否則請始終停用提款權限。

問題 4：在 shell 腳本中使用硬編碼機密的curl 安全性嗎？不會。 Shell 歷史記錄、進程清單和日誌檔案會暴露秘密；始終使用安全憑證注入機制。