Error Binance -1021 timestamp: penyebab dan cara memperbaikinya
Error API Binance -1021 INVALID_TIMESTAMP berarti timestamp pada permintaan bertanda tangan Anda berada di luar jendela yang diterima Binance. Pesannya biasanya Timestamp for this request is outside of the recvWindow atau was 1000ms ahead of the server's time. Dalam kebanyakan kasus jam Anda sendiri penyebabnya, jadi solusinya adalah menyinkronkannya, mengukur selisih terhadap waktu server Binance, dan menangani sisa jeda jaringan dengan benar. recvWindow lebih besar bisa menyembunyikan masalah, tetapi tidak boleh menjadi langkah pertama.
Sinkronkan jam mesin dengan layanan waktu, lalu bandingkan dengan waktu server Binance. Binance menerima permintaan saat timestamp kurang dari 1.000 ms di depan waktu servernya dan tidak lebih dari recvWindow di belakangnya. recvWindow default adalah 5.000 ms.
Arti error ini
Binance mensyaratkan parameter timestamp pada endpoint bertanda tangan, yaitu permintaan yang menyentuh akun Anda: menempatkan order atau membaca saldo. Nilainya harus waktu dalam milidetik saat permintaan dibuat. Binance memakainya untuk menolak permintaan basi atau yang diputar ulang, sehingga permintaan yang tertangkap tidak bisa dikirim ulang begitu saja nanti.
Pengecekannya tertulis dalam dokumentasi Binance:
if (timestamp < serverTime + 1000 && serverTime - timestamp <= recvWindow) { process } else { reject }
Baca itu sebagai dua batas terpisah, dan perhatikan pesan mana untuk yang mana.
- Terlalu jauh di depan: jika timestamp Anda 1.000 ms atau lebih di depan jam Binance, Anda mendapat
Timestamp for this request was 1000ms ahead of the server's time. Jam Anda terlalu cepat. - Terlalu jauh di belakang: jika timestamp Anda lebih tua dari
recvWindowsaat Binance memprosesnya, Anda mendapatTimestamp for this request is outside of the recvWindow. Jam Anda lambat, atau permintaan terlalu lama tiba.
Kedua batas tidak setara. Anda punya toleransi 5.000 ms pada sisi lambat secara default, tetapi hanya 1.000 ms pada sisi cepat, dan menaikkan recvWindow tidak berpengaruh pada sisi cepat.
Langkah 1: ukur selisihnya
Jangan menebak. Ambil waktu server dan bandingkan dengan jam Anda. Endpoint publik ini tidak memerlukan kunci. Untuk futures USD-margined adalah https://fapi.binance.com/fapi/v1/time, dan untuk spot https://api.binance.com/api/v3/time.
Pengecekan Python kecil tampak seperti ini:
import time, requests; t0 = time.time()*1000; s = requests.get("https://fapi.binance.com/fapi/v1/time").json()["serverTime"]; t1 = time.time()*1000; print("offset ms:", s - (t0 + t1) / 2, "round trip ms:", t1 - t0)
Ini memakai titik tengah pulang-pergi sebagai perkiraan terbaik kapan server membaca jamnya. Jalankan beberapa kali. Selisih positif berarti jam Binance di depan jam Anda, jadi jam Anda lambat. Selisih negatif berarti jam Anda cepat. Jika pulang-pergi besar atau sangat bervariasi, jaringan Anda bagian dari masalah. Panduan kami tentang selisih jam menjelaskan metode ini dan batasnya.
Langkah 2: sinkronkan jam Anda
Jika selisih lebih dari beberapa ratus milidetik, perbaiki jam Anda dulu. Itu menyelesaikan kebanyakan kasus.
- Linux: periksa dengan
timedatectl. Pasang dan aktifkanchronyjika tidak ada layanan yang menyinkronkan, lalu gunakanchronyc makestepuntuk mengoreksi selisih besar sekaligus. - Windows: buka pengaturan Tanggal dan Waktu dan gunakan «Sync now». Sinkronisasi default Windows jarang, jadi mesin bisa melenceng di antara sinkronisasi. Pertimbangkan layanan waktu yang lebih sering.
- macOS: aktifkan «Atur tanggal dan waktu secara otomatis» di pengaturan Tanggal dan Waktu.
- Docker: kontainer memakai jam host, jadi perbaiki host. Di Docker Desktop, mesin virtual internal bisa melenceng setelah laptop tidur, dan memulai ulang sering menghilangkan error ini.
- Mesin virtual dan server cloud: mesin yang dijeda atau dimigrasikan bisa kembali dengan waktu lama. Jalankan layanan waktu di dalamnya.
Dokumentasi NTP Pool menjelaskan penyiapan server waktu publik jika sistem Anda belum dikonfigurasi, meski kebanyakan penyedia cloud menawarkan layanan waktu internal sendiri, yang biasanya pilihan lebih baik.
Langkah 3: buat timestamp pada saat yang tepat
Jam yang benar masih bisa menghasilkan error ini jika kode membuat timestamp terlalu awal. Periksa penyebab berikut:
- Timestamp dibuat jauh sebelum dikirim. Buat tepat sebelum menandatangani dan mengirim. Jika permintaan melewati antrean atau thread lambat, timestamp menua saat menunggu.
- Loop percobaan ulang memakai ulang permintaan. Permintaan yang diulang memerlukan timestamp dan tanda tangan baru, kalau tidak akan gagal dengan error ini setelah beberapa percobaan.
- Satuan salah. Binance mengharapkan milidetik. Timestamp dalam detik punya sepuluh digit, bukan tiga belas, dan akan jauh di luar jendela.
- Pembatasan laju oleh klien Anda sendiri. Pembatas sisi klien yang menahan permintaan bertanda tangan beberapa detik akan membuatnya menua keluar jendela.
- Mesin yang terlalu sibuk. Saat CPU jenuh, jeda antara timestamp dan pengiriman bisa sangat panjang.
Langkah 4: gunakan selisih waktu di klien jika perlu
Pendekatan umum adalah mengambil waktu server saat mulai, menghitung selisih dengan jam Anda, dan menambahkannya pada setiap timestamp. Banyak pustaka klien menawarkan ini sebagai opsi, misalnya yang menyesuaikan selisih waktu secara otomatis.
Ini berguna saat Anda tidak bisa mengendalikan jam sistem, tetapi punya kelemahan: selisihnya usang saat jam Anda terus melenceng. Jika memakai pendekatan ini, segarkan secara berkala dan tangani error dengan menyegarkan sekali sebelum mengulang. Memperbaiki jam sistem adalah solusi jangka panjang yang lebih baik, karena semua perangkat lunak Anda ikut diuntungkan.
Langkah 5: pikirkan recvWindow dengan cermat
recvWindow adalah jumlah milidetik setelah timestamp saat permintaan tetap berlaku. Defaultnya 5.000. Dokumentasi Binance menggambarkannya sebagai cara menyatakan bahwa permintaan harus diproses dalam waktu tertentu atau ditolak, yang merupakan fitur keamanan dan bukan gangguan. Menaikkannya mungkin menghentikan error, tetapi pertimbangkan artinya. Anda memberi tahu Binance bahwa Anda rela order yang dibuat beberapa detik lalu dieksekusi sekarang. Di pasar cepat, trade yang diputuskan 30 detik lalu bisa menjadi trade yang sangat berbeda.
Jendela besar juga menutupi masalah sebenarnya, baik jam yang melenceng maupun jaringan yang tidak andal. Jendela besar sama sekali tidak membantu jika jam Anda cepat, karena batas 1.000 ms terpisah. Naikkan hanya sedikit, hanya sebagai langkah sementara, dan hanya setelah mengukur yang terjadi. Jika Anda merasa perlu jendela besar, masalah sebenarnya ada di tempat lain.
Saat masalahnya jaringan atau Binance
Jika jam Anda benar dan timestamp dibuat pada saat yang tepat, lihat jalurnya. Latensi tinggi, kehilangan paket, atau proksi yang padat bisa membuat permintaan cukup lama untuk jatuh keluar jendela. Waktu pulang-pergi dari Langkah 1 akan menunjukkan ini. API Binance juga berada di balik infrastrukturnya sendiri, jadi jeda singkat mungkin terjadi pada waktu sibuk.
Error sesekali yang terisolasi biasanya tidak berbahaya jika ditangani dengan membangun ulang dan mengirim ulang permintaan. Ledakan tiba-tiba di banyak mesin yang sebelumnya baik menunjuk ke jaringan atau bursa. Bandingkan dengan pembacaan kami untuk Binance, termasuk selisih jam dan waktu respons terbarunya, dan periksa pengumumannya. Namun data kami hanya menampilkan API publik Binance seperti terlihat dari lokasi kami.
Menanganinya dalam kode
Klien yang tangguh memperlakukan -1021 sebagai kondisi yang dikenal dan bisa dipulihkan, bukan kegagalan umum.
- Buat ulang, jangan kirim ulang. Bangun permintaan baru dengan timestamp dan tanda tangan baru.
- Periksa sebelum mengulang order. Penolakan berarti permintaan ini tidak diproses, tetapi jika percobaan sebelumnya punya error lain, periksa status order lebih dulu agar tidak ganda. Gunakan ID order klien yang unik agar duplikat bisa terdeteksi.
- Batasi percobaan ulang. Mengulang dalam loop ketat bisa membawa Anda ke batas laju, dan panduan batas laju kami menjelaskan akibatnya.
- Catat selisih dan pulang-pergi. Saat error ini berulang, catatan langsung menunjukkan apakah jam melenceng atau jaringan memburuk.
- Pasang peringatan. Tingkat -1021 yang naik adalah peringatan dini bahwa jam suatu mesin bermasalah.
Apakah bursa lain punya error yang sama?
Ya. Bursa apa pun yang memakai permintaan bertanda tangan punya versi pengecekan ini, dengan kode dan jendela berbeda. Bybit misalnya mengecek timestamp terhadap waktu servernya dan punya parameter recv_window, dan OKX mensyaratkan timestamp di header permintaannya. Sarannya sama, tetapi baca dokumentasi tiap bursa untuk batas tepatnya.
Pertanyaan umum tentang error -1021
Mengapa berfungsi di laptop dan gagal di server, atau sebaliknya?
Karena tiap mesin punya jam dan rute sendiri ke Binance. Jalankan pengecekan selisih di keduanya. Server cloud biasanya punya waktu yang baik, sedangkan laptop yang sering tidur sering tidak.
Mengapa error tiba-tiba mulai padahal tidak ada yang berubah?
Jam melenceng perlahan. Selisih bisa tumbuh berminggu-minggu sampai melewati batas. Pembaruan sistem juga bisa menonaktifkan layanan waktu, dan pindah jaringan bisa menaikkan latensi.
Amankah menyetel recvWindow ke maksimum?
Itu menghentikan banyak error, tetapi berarti Binance bisa mengeksekusi permintaan yang jauh lebih tua dari maksud Anda, di pasar yang mungkin sudah bergerak. Kami memperlakukannya paling jauh sebagai langkah sementara.
Apakah error ini berarti Binance sedang down?
Tidak. Justru ini menunjukkan permintaan Anda mencapai Binance dan ditolak, jadi server sedang menjawab. Saat insiden Anda biasanya melihat timeout atau respons 5xx. Jika keduanya muncul bersamaan, periksa juga jalur jaringannya.
Perbaiki dalam urutan ini
- Baca yang mana dari dua pesan yang Anda terima.
- Ukur selisih Anda terhadap waktu server Binance.
- Sinkronkan jam sistem dan pastikan tetap sinkron.
- Buat timestamp tepat sebelum menandatangani dan mengirim.
- Pastikan percobaan ulang membangun ulang timestamp dan tanda tangan.
- Baru kemudian pertimbangkan perubahan kecil pada recvWindow.
Angka dalam panduan ini untuk menunjukkan metodenya dan bukan nasihat investasi. Untuk keputusan Anda, ambil nilai terkini dari halaman resmi bursa, ulangi perhitungan dengan posisi Anda sendiri, dan bandingkan hasilnya dengan riwayat transaksi. Jika Anda melihat kesalahan pada data kami, tulis ke alamat di halaman tentang kami; koreksi kami terbitkan dengan menjelaskan apa yang berubah dan mengapa.
Bacaan terkait: Selisih jam dan kuotasi basi · Batas laju API bursa dan error 429 · Mengapa API bursa mengembalikan 403 atau 451
Sumber
Binance · Kode error · Binance · Informasi umum dan keamanan waktu · NTP Pool Project · Tentang Tickmark
Panduan lain
Apa itu funding rate pada perpetual futures kripto? Penjelasan sederhana
Funding rate adalah pembayaran rutin antara trader yang memegang sisi berlawanan pada kontrak perpetual futures. Kontrak ini ada karena perpetual tidak pernah jatuh tempo, sehingga perlu mekanisme lain untuk menjaga harganya tetap dekat dengan aset dasarnya. Saat rate positif, long membayar short; saat negatif, short membayar long. Bursa menetapkan rumusnya, tetapi di bursa-bursa besar uang itu berpindah antar trader.
Cara membandingkan funding rate antar bursa: penyelesaian 8 jam vs 4 jam
Anda tidak bisa membandingkan dua funding rate hanya dari persentasenya. Sebuah rate baru bermakna setelah Anda tahu seberapa sering dikenakan, apakah Anda long atau short, dan apakah kedua pembacaan menggambarkan kontrak yang sama pada saat yang sama. +0,01% yang sama berbiaya dua kali lipat per hari pada jadwal empat jam dibanding jadwal delapan jam, dan apa yang menjadi biaya long adalah pendapatan bagi short.
Apa arti funding rate negatif? Siapa membayar, dan apa yang tidak disampaikannya
Funding rate negatif berarti trader yang memegang posisi short membayar trader yang memegang posisi long pada penyelesaian berikutnya. Biasanya ini terjadi saat kontrak perpetual diperdagangkan di bawah harga indeksnya, yang sering mencerminkan shorting besar-besaran atau lindung nilai. Rate negatif tidak berarti harga akan segera turun atau naik, dan bukan pendapatan gratis bagi long, karena harga bisa bergerak melawan mereka jauh melebihi pembayarannya.
Cara mengubah funding rate menjadi APR, dan mengapa angkanya bisa menyesatkan
Untuk menyetahunkan funding rate, kalikan rate per penyelesaian dengan jumlah penyelesaian dalam sehari, lalu dengan 365. Rate 0,01% setiap delapan jam menjadi 0,01% × 3 × 365 = 10,95% setahun. Ini menempatkan kontrak dengan jadwal berbeda pada satu skala, sehingga bisa dibandingkan. Angka itu tidak memberi tahu berapa yang akan Anda peroleh atau bayar dalam setahun, karena mengasumsikan rate hari ini tidak pernah berubah.
Arbitrase funding rate: cara kerjanya dan apa yang menggerus keuntungan
Arbitrase funding rate berarti memegang dua posisi yang saling mengimbangi pada aset yang sama sehingga pergerakan harga kurang lebih saling meniadakan, sambil mengumpulkan pembayaran funding di satu sisi. Versi klasiknya membeli spot dan short perpetual. Versi kedua melakukan short perpetual di bursa dengan rate lebih tinggi dan long di bursa dengan rate lebih rendah. Strategi ini sering disebut bebas risiko. Padahal tidak. Risikonya hanya berbeda dari trade berarah biasa.
Harga mark vs harga terakhir vs harga indeks: mana yang melikuidasi Anda?
Perpetual futures menampilkan tiga harga yang mudah tertukar. Harga terakhir adalah tempat transaksi terbaru terjadi. Harga indeks adalah rata-rata harga spot di beberapa bursa. Harga mark adalah perkiraan bursa tentang nilai wajar kontrak, dan di bursa-bursa besar harga inilah yang menentukan keuntungan belum terealisasi dan apakah Anda dilikuidasi. Mengetahui fungsi tiap harga menjelaskan mengapa posisi bisa dilikuidasi meski grafik tidak pernah menyentuh level likuidasi Anda.
Berapa biaya market order sebenarnya: biaya transaksi, spread, dan slippage
Biaya di halaman tarif bursa hanyalah sebagian dari biaya market order. Sisanya berasal dari harga yang benar-benar Anda dapat, yang bergantung pada arah trade, ukuran order, dan kedalaman order book saat itu. Untuk membandingkan bursa secara adil, ukur harga isi rata-rata terhadap satu harga acuan, lalu tambahkan biaya transaksi, dan berhati-hatilah agar tidak menghitung spread dua kali.
Cara memperkirakan slippage dari kedalaman order book sebelum bertransaksi
Slippage adalah selisih antara harga yang Anda harapkan dan harga rata-rata yang benar-benar Anda dapat. Sebagian besar bisa diperkirakan sebelum menempatkan order, karena order book menunjukkan berapa yang tersedia di tiap harga. Jumlahkan tingkat di sisi yang akan Anda konsumsi sampai menutup ukuran Anda, hitung harga rata-rata, dan bandingkan dengan harga tengah. Perkiraan hanya sebaik potret asalnya, dan order book menipis pada saat Anda paling mungkin membutuhkannya.
Biaya maker dan taker: cara membandingkan biaya transaksi bursa kripto
Maker menambahkan order ke order book yang menunggu terisi. Taker mengisi terhadap order yang sudah ada di sana. Kebanyakan bursa mengenakan lebih banyak pada taker, karena maker menyediakan likuiditas yang menjadi lawan transaksi orang lain. Membandingkan bursa hanya dari biaya utama menyesatkan: Anda perlu tahu sisi mana yang biasanya Anda pakai, tingkat apa yang sebenarnya berlaku untuk volume Anda, dan bagaimana biaya itu dibanding slippage serta funding pada trade yang sama.
Cara memeriksa apakah bursa kripto sedang down: panduan langkah demi langkah
Saat bursa berhenti berfungsi bagi Anda, pertanyaan pertama adalah apakah bursa itu down untuk semua orang atau hanya untuk Anda. Biasanya bisa dijawab dalam beberapa menit: periksa halaman status bursa, periksa pengukuran independen, coba jaringan lain, dan uji API publik langsung. Setiap sumber melihat hal berbeda, jadi satu halaman hijau tidak membuktikan semuanya baik, dan satu permintaan gagal tidak membuktikan bursa down.
Apakah bursa benar-benar down? Cara membaca uptime API dan catatan insiden
Uptime menggambarkan porsi permintaan yang berhasil ke layanan tertentu, selama periode tertentu, dari rute jaringan tertentu. Uptime tidak memastikan Anda bisa menempatkan order, menarik dana, atau memercayakan aset pada suatu bursa. Angka seperti 99,9% hanya berguna jika Anda tahu apa yang diuji, dari mana, dan berapa lama, jadi panduan ini menjelaskan cara membaca detail itu di halaman kami dan di tempat lain.
Apa yang harus dilakukan saat bursa kripto down ketika Anda punya posisi terbuka
Jika bursa berhenti merespons saat Anda memegang posisi, tugas pertama adalah mencari tahu apa yang sebenarnya rusak, kedua jangan memperburuknya, dan ketiga mengurangi risiko lewat jalur apa pun yang masih berfungsi. Jangan terus mengirim ulang order yang sama, karena percobaan sebelumnya mungkin sudah berhasil. Periksa aplikasi seluler dan API sebagai jalur alternatif, pertimbangkan lindung nilai di tempat lain jika eksposur besar, dan catat kejadiannya jika nanti perlu diajukan.
Mengapa API bursa menolak timestamp: selisih jam dan kuotasi basi
Respons cepat bisa berisi kuotasi lama. Latensi pulang-pergi, selisih jam, dan umur kuotasi menggambarkan bagian berbeda dari suatu permintaan, dan mencampurnya bisa membuat ketidakcocokan jam tampak seperti umpan pasar yang terlambat. Panduan ini menjelaskan masing-masing dengan contoh, menunjukkan cara kami memperkirakannya, dan membahas yang harus dilakukan saat API bursa menolak permintaan Anda karena waktu.
Batas laju API bursa kripto: arti error 429 dan cara tetap di bawahnya
HTTP 429 berarti Anda mengirim terlalu banyak permintaan dalam waktu tertentu, dan server meminta Anda melambat. Ini bukan insiden. Setiap bursa menghitung permintaan secara berbeda: Binance memakai bobot untuk tiap endpoint dan memblokir alamat IP yang terus berlanjut setelah 429, Bybit memblokir IP yang melewati 600 permintaan dalam lima detik, dan OKX menetapkan batas per endpoint serta mengembalikan kode error 50011. Tetap di bawah batas berarti membaca header respons, mundur dengan benar, dan memakai WebSocket jika bisa.
Mengapa API bursa mengembalikan 403 atau 451: blokir dan wilayah
403 berarti server memahami permintaan Anda dan menolak melaksanakannya. 451 berarti akses ditolak karena alasan hukum. Pada API bursa kripto, 403 bisa berupa firewall web, batas permintaan, kunci tanpa izin, atau blokir wilayah, jadi kodenya saja tidak menunjukkan yang mana. Isi respons, dokumentasi bursa, dan perbandingan dari jaringan lain biasanya menunjukkannya. Pembatasan nyata berlaku pada Anda karena suatu alasan, jadi respons yang benar adalah mencari tahu apakah layanan tersedia di tempat Anda.
Sebelum membuka akun bursa kripto di Indonesia: daftar cek
Sebelum membuka akun di bursa kripto, cek empat hal: apakah bursa itu boleh melayani orang di tempat Anda tinggal, apakah regulator di negara Anda memberinya izin, apakah situs di depan Anda adalah situs yang asli, dan bagaimana bursa itu berjalan belakangan ini. Mengisi formulir pendaftaran hanya butuh sepuluh menit. Memperbaiki pilihan yang salah bisa makan waktu berbulan-bulan, dan kadang tidak bisa diperbaiki sama sekali. Panduan ini membahas setiap pengecekan satu per satu, dengan Binance dan OKX sebagai contoh karena keduanya paling sering ditanyakan pembaca kami, serta menjelaskan kondisi di Indonesia pada November 2026.