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. 추가 공백이나 같음 또는 앰퍼샌드의 URL 인코딩 없이 타임 스탬프=1718234567890 으로 정확하게 쿼리 문자열을 작성합니다.

3. UTF-8로 인코딩된 비밀 키와 원시 쿼리 문자열을 사용하여 HMAC-SHA256 서명을 계산한 다음 접두사 또는 접미사 없이 16진수 다이제스트를 출력합니다.

4. 결과 서명을 헤더가 아닌 서명 매개변수로 전달하고 매개변수와 쿼리 문자열 모두에 타임스탬프를 포함합니다.

5. API 키 값에는 X-MBX-APIKEY 헤더를 독점적으로 사용하십시오. URL이나 본문에 포함하지 마세요.

시스템 시간 동기화

1. Linux 시스템에서 timedatectl status를 실행하여 NTP 서비스가 활성 상태이고 동기화되었는지 확인합니다.

2. exchange.fetch_time() 을 통해 바이낸스 서버 시간을 가져오고 로컬 에포크 밀리초와 비교합니다.

3. 편차가 5000ms를 초과하는 경우 sudo chronyc makestep 을 사용하여 즉시 수정하도록 합니다.

4. 'options': {'adjustForTimeDifference': True} 로 CCXT를 초기화하여 자동 오프셋 보상을 활성화합니다.

5. 실시간 거래 세션 중에 시간을 수동으로 조정하지 마세요. NTP 기반 동기화에만 의존하세요.

속도 제한 동작

1. 내장된 조절 논리를 활성화하려면 교환 인스턴스화 시 활성화RateLimit: True를 설정합니다.

2. 각 호출 후 X-MBX-USED-WEIGHT-1M 응답 헤더를 모니터링하여 분당 1200 한도에 대한 실시간 사용량을 추적합니다.

3. 현재 분 창 내에서 체중 소비가 1100을 초과하는 경우 동적 수면 간격을 삽입합니다.

4. 순차 기호 요청을 fetch_tickers([symbols]) 와 같은 일괄 엔드포인트로 대체하여 총 호출 수를 줄입니다.

5. 빈 응답이나 지연된 승인을 HTTP 429 오류뿐만 아니라 잠재적인 속도 제한 표시기로 처리하십시오.

환경별 자격 증명 처리

1. 엄격한 들여쓰기 및 간격 규칙에 따라 소스 제어 외부의 외부 creds.yml 파일에 API 키를 저장합니다.

2. 우발적인 커밋을 방지하려면 creds.yml을 .gitignore 에 영구적으로 추가하세요.

3. 필드 존재 및 유형 무결성을 검증하는 전용 로더 기능을 사용하여 프로그래밍 방식으로 자격 증명을 로드합니다.

4. 디버깅을 위해서라도 Python 스크립트에 키를 하드코딩하거나 하위 프로세스에 액세스할 수 있는 환경 변수에 저장하지 마세요.

5. API 관리 인터페이스를 통해 손상되거나 오래된 키를 즉시 교체합니다. 이전 키는 삭제되면 복구할 수 없습니다.

자주 묻는 질문

Q1: API 키와 비밀번호가 올바른데도 요청이 -1022를 반환하는 이유는 무엇입니까? 타임스탬프 불일치, 잘못된 쿼리 문자열 또는 잘못된 HMAC 입력 순서로 인해 서명 확인이 실패합니다. 세 가지 구성 요소를 모두 독립적으로 확인하세요.

Q2: 여러 서버에서 동일한 API 키를 재사용할 수 있나요? 아니요. 각 서버에는 자체 IP 화이트리스트 키가 있어야 합니다. 키를 공유하면 보안 정책을 위반하고 자동 취소가 발생합니다.

Q3: 실수로 "출금" 권한을 활성화한 경우 어떻게 되나요? API 키는 완전한 자산 전송 기능을 얻습니다. 모든 타협은 되돌릴 수 없는 자금 손실로 이어집니다. 명시적으로 요구되지 않는 한 항상 출금 허가를 비활성화하십시오.

Q4: 쉘 스크립트에서 하드코딩된 비밀과 함께 컬을 사용하는 것이 안전합니까? 아니요. 셸 기록, 프로세스 목록, 로그 파일은 비밀을 노출합니다. 대신 항상 안전한 자격 증명 주입 메커니즘을 사용하십시오.