Pool Sedang Down: Cara Memastikan Masalahnya Bukan di ASIC Anda, dan Apa yang Harus Dilakukan di Jam Pertama

*Last updated: 09.09.2026. POOL BTC.*

TL;DR

Ketika hashrate di panel pool anjlok ke nol, yang salah tidak selalu pool. Dalam sebagian besar kasus penyebabnya ada di antara ASIC Anda dan server stratum: router, provider, catu daya, board yang kepanasan, firmware yang baru dipasang. Membedakan satu dari yang lain bisa dilakukan dalam lima menit tanpa beranjak dari laptop: lihat apa yang ditampilkan miner itu sendiri, cek apakah pool juga down bagi miner lain, lalu bandingkan hashrate lokal dengan hashrate di pool. Jam pertama sebaiknya dipakai bukan untuk panik dan bukan untuk pindah pool, melainkan untuk diagnosis berurutan dan untuk mengaktifkan stratum cadangan yang seharusnya sudah ada di konfigurasi jauh sebelumnya.

POOL BTC bukan pool, melainkan situs perbandingan pool yang independen. Kami tidak menuduh pool tertentu mengalami gangguan: di bawah ini metodenya, bukan pembedahan kejadian down milik siapa pun.

Bagaimana membedakan pool yang down dari masalah di sisi Anda sendiri?

Tanda utama pool sedang down: miner bekerja, hashrate di perangkat normal, tetapi koneksi ke stratum terputus atau share terkirim tanpa jawaban. Sebaliknya, jika di panel ASIC itu sendiri hashrate turun, chip terlepas, atau perangkat reboot berulang kali, pool sama sekali tidak terlibat, masalahnya ada di perangkat keras, catu daya, atau jaringan sampai ke provider.

Mari kita urai berdasarkan gejala. Anda harus melihat dua tempat sekaligus: panel miner (hashrate lokal) dan statistik akun di pool (hashrate pool).

Ada satu kasus khusus yang paling sering dikira pool down: pengaturan yang baru saja dibuat. Kalau hashrate di pool memang tidak pernah muncul sama sekali, itu bukan gangguan, melainkan salah ketik pada nama worker atau port yang tertutup. Gangguan terlihat berbeda: sudah berjalan berhari-hari, lalu berhenti sekaligus.

Apa yang ditampilkan panel miner saat koneksi putus dan apa arti accepted, rejected, stale?

Di panel ASIC ada tiga penghitung untuk setiap pool: accepted (share diterima), rejected (ditolak), stale (datang terlambat, pekerjaannya sudah tidak relevan). Saat koneksi ke stratum terputus, status pool berubah menjadi dead atau disconnected, penghitung accepted membeku, dan miner mulai mencoba terhubung ke pool berikutnya dalam daftar, kalau memang ada di sana.

Apa yang ada di balik istilah-istilah itu:

• Accepted. Pool menerima share Anda dan menghitungnya ke dalam statistik. Ini satu-satunya penghitung yang berubah menjadi uang.
• Rejected. Pool menerima share tersebut, tetapi tidak menghitungnya. Penyebabnya bermacam-macam: pekerjaan sudah kedaluwarsa, duplikat, difficulty terlalu rendah, kesalahan otorisasi.
• Stale. Kasus khusus dari penolakan: share dihitung untuk tugas yang sudah dibatalkan pool karena ada blok baru yang ditemukan di jaringan. Semakin besar latensi ke server, semakin sering hal ini terjadi.
• Difficulty accepted. Pada sebagian firmware ada baris tersendiri berisi jumlah difficulty dari share yang diterima. Angka ini lebih informatif daripada penghitung jumlah keping, karena dengan vardiff banyaknya share saja tidak berarti apa-apa.

Satu baris lagi yang layak diperhatikan: waktu share terakhir yang diterima (last share). Kalau angkanya terus bertambah dan sudah lewat beberapa menit padahal hashrate stabil, koneksi sebenarnya sudah mati, walaupun status pool masih hijau.

Mekanika share dan alasan jumlahnya tidak sama dengan pendapatan dibahas lebih rinci di artikel tentang skema pembayaran FPPS dan PPLNS.

Berapa persen reject yang dianggap wajar, dan berapa yang sudah jadi sinyal?

Tidak ada angka universal: porsi share yang ditolak bergantung pada jarak ke server stratum, kualitas jalur, firmware, dan pengaturan vardiff. Patokannya bukan nilai absolut, melainkan garis dasar Anda sendiri: catat persentase normal Anda pada hari yang tenang, lalu anggap penyimpangan semua yang jelas naik dari angka itu dan bertahan di sana.

Pendekatan praktis sebagai pengganti angka ajaib:

1. Ambil porsi rejected selama satu hari penuh operasi normal. Itulah titik nol Anda.
2. Pantau bukan nilai sesaat, melainkan rata-rata per jam. Lonjakan tunggal saat pergantian blok itu wajar, bukan gangguan.
3. Naiknya porsi ketika hashrate lokal tidak berubah berarti ada masalah pada jalur atau pada pool, bukan pada perangkat keras.
4. Naiknya porsi bersamaan dengan turunnya hashrate lokal berarti perangkat keras.

Ada tiga pool yang menyebutkan patokan mereka sendiri, dan angkanya berbeda satu sama lain lebih jauh daripada para miner yang berdebat di grup obrolan. AntPool di pusat bantuannya menulis bahwa porsi share ditolak di bawah 1 persen dianggap normal, sedangkan share usang sekitar 0,5 persen atau kurang. ViaBTC menyebut rentang normal untuk penolakan berada dalam batas 3 persen. F2Pool menganggap porsi share yang terlambat sekitar 2 persen masih masuk akal. Sebaran dari 0,5 sampai 3 persen di antara tiga pool besar itulah jawaban atas pertanyaan soal batas wajar: tidak ada batas wajar yang berlaku umum, yang ada adalah pengaturan pool tertentu.

Catatan soal sumber: halaman dukungan pool-pool tersebut tertutup dari pemeriksaan otomatis, dan rumusan di atas kami catat dari cuplikan pencarian publik mereka, bukan dari teks lengkap halamannya. Sebelum bersandar pada angka tertentu, buka pusat bantuan pool Anda sendiri dan cocokkan dengan versi yang berlaku sekarang.

Tidak ada satu pun pihak yang menerbitkan ambang batas kapan kerugian mulai terasa, dan mengarang angkanya tidak perlu: mekanikanya bisa dihitung di kepala. Share yang ditolak tidak dibayar, jadi porsi penolakan kurang lebih sama dengan porsi pendapatan yang hilang. Satu persen reject berarti kira-kira satu persen pendapatan lewat begitu saja, tiga persen berarti tiga. Apakah demi itu farm perlu dikonfigurasi ulang, tergantung ukuran farm-nya, bukan pada rekomendasi orang lain.

Yang jelas tidak wajar dan tidak butuh statistik: porsi yang ditolak mendekati seratus persen. Itu hampir selalu difficulty yang salah, firmware rusak, atau koneksi diblokir oleh perantara, bukan pool yang kelebihan beban.

Ke mana harus melihat untuk memastikan pool memang down?

Memastikan pool down selalu berarti sumber kedua yang independen. Panel Anda sendiri saja tidak cukup: tampilannya sama saja baik untuk gangguan pool maupun untuk koneksi putus di provider Anda. Urutan pemeriksaan dari yang tercepat ke yang terlambat memakan waktu sekitar lima menit dan hampir selalu memberi jawaban yang jelas.

1. Statistik hashrate akun di pool. Kalau panel web terbuka dan menampilkan nol untuk worker Anda, servernya hidup, hanya saja share Anda yang tidak sampai ke sana. Kalau panelnya sama sekali tidak termuat, masalahnya lebih luas.
2. Halaman status pool. Sebagian pool punya halaman status layanan tersendiri. Alamatnya sebaiknya dicari jauh hari dan disimpan di bookmark, bukan dicari saat gangguan terjadi.
3. Monitor dan explorer pihak ketiga. Pengamat publik untuk distribusi hashrate memperlihatkan apakah pool sedang menemukan blok saat ini. Jeda panjang pada pool besar adalah tanda tidak langsung, tetapi kuat.
4. Media sosial dan grup obrolan pool. Akun resmi dan kanal Telegram biasanya tahu soal gangguan lebih cepat daripada halaman status diperbarui. Di sana juga terlihat apakah miner lain ikut mengeluh.
5. Pemeriksaan rute dari sisi Anda. Perintah telnet atau nc biasa ke alamat dan port stratum dari komputer mana pun di jaringan yang sama memisahkan pool yang tumbang dari pemblokiran di provider dalam sepuluh detik.

Kalau panel pool terbuka, blok terus ditemukan, grup obrolan sepi, sementara share Anda tidak diterima, berarti gangguannya ada di Anda, bukan di pool.

Untuk apa backup pool dan bagaimana cara menuliskan stratum cadangan dengan benar?

Pool cadangan adalah satu baris di konfigurasi miner, tempat perangkat berpindah sendiri ketika stratum utama tidak menjawab. Tanpa baris itu, saat koneksi putus ASIC hanya memutar kipas dan tidak menghasilkan apa pun sampai Anda turun tangan. Dengan baris itu, waktu berhenti menyusut menjadi durasi penyambungan ulang, yang diukur dalam detik, bukan dalam jam tidur Anda.

Seperti apa bentuknya di konfigurasi. Firmware berbeda dalam detail, tetapi prinsipnya satu: daftar pool berdasarkan prioritas, miner menelusurinya dari atas ke bawah.

```

pool1: stratum+tcp://[ALAMAT POOL UTAMA]:[PORT] worker: akun.worker

pool2: stratum+tcp://[ALAMAT POOL CADANGAN]:[PORT] worker: akun2.worker

pool3: stratum+tcp://[ALAMAT POOL KETIGA]:[PORT] worker: akun3.worker

```

Aturan yang tanpanya cadangan tidak akan bekerja:

1. Pool kedua berarti pool yang berbeda, bukan port lain dari pool yang sama. Alamat cadangan di dalam infrastruktur yang sama tidak akan menyelamatkan Anda saat infrastruktur itu tumbang. Port cadangan dari pool utama letakkan di baris ketiga, bukan kedua.
2. Akun di pool cadangan harus sudah dibuat dan diverifikasi sejak awal. Mendaftar saat gangguan berlangsung akan melahap jam pertama yang berharga itu.
3. Alamat pembayaran di pool cadangan harus sudah terisi. Kalau tidak, hasil mining akan menggantung di saldo yang baru Anda datangi sebulan kemudian.
4. Uji perpindahannya secara manual. Matikan pool utama di antarmuka selama beberapa menit dan pastikan share mengalir ke pool cadangan, lalu setelah dinyalakan lagi miner kembali ke pool semula.
5. Perhitungkan skema pembayaran. Berpindah bolak-balik di antara pool PPLNS mengosongkan akumulasi dalam jendela sebanyak dua kali, jadi lebih masuk akal menempatkan pool dengan skema yang lebih sederhana sebagai cadangan. Perbedaan mekanikanya dibahas di perbandingan FPPS dan PPLNS.

Jumlah titik masuk yang tersedia di tiap pool berbeda-beda, dan hal itu terlihat dari dokumentasi mereka sendiri. Kami menghitung host stratum unik untuk BTC di halaman koneksi enam pool.

Yang penting di sini bukan bahwa satu pool punya delapan host sementara pool lain punya satu. Yang penting, semua alamat itu mengarah ke satu infrastruktur: alamat-alamat itu menyelamatkan Anda dari tumbangnya sebuah region, tetapi bukan dari tumbangnya pool. Justru karena itu baris kedua di konfigurasi harus menunjuk ke luar.

Berapa uang yang benar-benar hilang per jam berhenti dan bagaimana menghitungnya sendiri?

Kerugian per jam berhenti dihitung dalam satu baris: pendapatan harian perangkat Anda, dibagi 24, dikalikan porsi waktu berhenti. Tidak perlu model yang rumit di sini, karena pendapatan di pool bersifat linier terhadap hashrate. Yang penting hanya memakai hashprice terkini, bukan angka dari artikel setengah tahun lalu, jika tidak kesalahannya bisa berlipat ganda.

Rumusnya:

```

kerugian = (hashrate dalam TH/s × hashprice dalam USD per TH/s per hari) / 24 × jam berhenti

```

Hashprice adalah pendapatan per satu terahash per hari sebelum dikurangi biaya listrik. Angkanya berubah setiap hari mengikuti kurs dan difficulty, jadi masukkan nilai terbaru.

Hashprice sengaja tidak kami patok sebagai angka di dalam teks. Nilainya berubah setiap hari mengikuti kurs dan difficulty, dan angka dari artikel sebulan lalu memberi kesalahan berlipat, bukan sekadar beberapa persen. Masukkan nilai terbaru pada hari perhitungan: angkanya ditampilkan oleh indeks hashprice publik dan oleh kalkulator kami.

Yang penting jangan terlupa saat menghitung:

• Listrik saat berhenti tetap terpakai sebagian. Kalau miner menyala tetapi tidak bisa mengirim share, ia tetap mengonsumsi daya. Kerugian nyata per jam lebih besar daripada pendapatan yang hilang, ditambah biaya konsumsi tersebut.
• PPLNS menghukum waktu berhenti dua kali. Pada skema akumulatif Anda bukan hanya tidak menghasilkan selama satu jam, tetapi juga kehilangan posisi di jendela, yang tidak pulih seketika. Pada skema serupa PPS, kerugiannya persis sama dengan rumus di atas.
• Hitung untuk seluruh farm, bukan untuk satu mesin. Satu jam berhenti pada sepuluh perangkat berharga sepuluh kali lebih mahal, dan pada angka itulah keputusan soal pool cadangan terbentuk dengan sendirinya.

Menghitung pendapatan untuk hashrate Anda dan parameter jaringan saat ini lebih nyaman dilakukan di kalkulator, bukan di kepala.

Apa yang harus dilakukan di jam pertama: daftar periksa langkah demi langkah

1. Menit 0-2. Lihat hashrate lokal di panel miner. Kalau turun bersamaan dengan hashrate pool, berarti perangkat keras, dan Anda tidak perlu melanjutkan daftar ini.
2. Menit 2-5. Periksa status pool dan waktu share terakhir yang diterima. Status dead dan waktu yang terus bertambah menegaskan koneksi putus.
3. Menit 5-10. Buka panel pool dan halaman statusnya. Kalau tidak ada yang terbuka, termasuk situs lain, berarti masalahnya di jalur Anda.
4. Menit 10-15. Periksa ketersediaan stratum dari perangkat lain di jaringan yang sama, lalu lewat internet seluler. Perbedaan hasilnya menunjuk ke provider atau router.
5. Menit 15-20. Tengok grup obrolan dan media sosial pool. Keluhan massal dalam beberapa menit terakhir menutup pertanyaannya.
6. Menit 20-30. Pastikan cadangan benar-benar aktif. Kalau pool cadangan belum ada di konfigurasi, tuliskan sekarang, inilah satu-satunya tindakan yang langsung mengembalikan pendapatan saat ini juga.
7. Menit 30-45. Jangan sentuh apa pun lagi. Reboot massal farm, flash ulang firmware, dan mengubah difficulty saat gangguan milik orang lain hanya menambahkan gangguan kedua di atas yang pertama.
8. Menit 45-60. Catat faktanya. Waktu mulai, tangkapan layar panel, waktu share terakhir, jawaban pool. Tanpa itu pembicaraan soal kompensasi berubah menjadi adu ingatan.

Kapan waktu berhenti jadi alasan pindah pool, dan kapan tidak?

Satu kali gangguan bukan alasan untuk pindah. Infrastruktur bisa tumbang di semua tempat, dan biaya pindah pool sering melebihi kerugian beberapa jam berhenti. Alasannya baru muncul ketika waktu berhenti berulang, berlangsung lama, dan tidak disertai komunikasi yang jelas: diamnya pool saat gangguan lebih mahal daripada gangguan itu sendiri.

Sebelum pindah, hitung dulu harga kepindahan itu sendiri: pengosongan jendela di PPLNS, menunggu ambang pembayaran baru, waktu untuk konfigurasi ulang. Kalau Anda condong ke solo mining sebagai cara lepas dari ketergantungan pada infrastruktur orang lain, lihat dulu perbandingan solo dan pool, di sana ketergantungan yang sama hanya berganti bentuk.

Mengapa hampir tidak ada pool yang menerbitkan uptime dan bagaimana menilai keandalan secara tidak langsung?

Halaman uptime publik adalah kewajiban yang tidak menguntungkan untuk diambil: angka apa pun akan menjadi bahan tuntutan dan perbandingan, sementara pengukuran yang jujur harus dilakukan dari luar. Karena itu sebagian besar pool membatasi diri pada statistik blok yang ditemukan dan hashrate. Keandalan terpaksa dinilai secara tidak langsung, lewat tanda-tanda yang bisa diamati, bukan lewat persentase yang diklaim.

Apa yang harus dilihat ketika angka uptime tidak ada:

• Keteraturan blok yang ditemukan. Pada pool besar, jedanya bisa diprediksi dari porsinya di jaringan. Keheningan yang panjang secara tidak wajar terlihat di explorer publik mana pun.
• Adanya halaman status dan riwayat insiden. Fakta bahwa pool memelihara catatan gangguan yang terbuka untuk umum bicara lebih banyak daripada angka cantik 99,9.
• Kecepatan dan isi komunikasinya. Pesan di grup obrolan pada menit-menit pertama gangguan lebih berharga daripada unggahan permintaan maaf keesokan harinya.
• Jumlah titik masuk yang independen. Region berbeda, alamat stratum berbeda, dukungan beberapa port. Hal ini menurunkan peluang Anda kehilangan koneksi sepenuhnya.
• Ulasan miner tentang gangguan di masa lalu. Bukan tentang ada tidaknya gangguan, melainkan tentang apakah statistiknya cocok setelah gangguan itu.

Kami memeriksa materi publik dari delapan pool pada 09.09.2026. Halaman status yang lengkap dengan riwayat insiden dan angka uptime hanya ditemukan pada satu pool: Luxor menerbitkannya di uptime.luxor.tech, dengan rincian per layanan (antarmuka pool 99,766 persen, pemrosesan statistik 99,956 persen, sebagian layanan 100 persen) dan dengan catatan tiga bulan terakhir. Foundry punya status.foundry.ac, tetapi itu status layanan korporat Foundry Digital, bukan halaman terpisah untuk mining pool-nya. F2Pool memelihara rubrik pengumuman berisi unggahan tentang insiden, tetapi itu bukan halaman status. Pada ViaBTC angka 99,99 persen muncul di materi pemasaran, sedangkan halaman tempat angka itu bisa diverifikasi tidak kami temukan. Pada AntPool, Braiins Pool, Binance Pool, dan Ocean, halaman status publik tidak terdeteksi lewat pencarian. Yang terakhir ini berarti persis «tidak ditemukan dalam rangka pemeriksaan», bukan ketiadaan yang terjamin.

Pemeriksaan halaman publik pool, 09.09.2026.

Parameter ringkas para pool, termasuk skema pembayaran, komisi, dan ambang batas, terkumpul di kartu pool. Data uptime tidak ada di sana persis karena alasan di atas: tidak ada yang bisa dibandingkan selama pool tidak menerbitkannya.

Ringkasnya

Pool tidak sesering itu benar-benar down seperti yang terasa di menit pertama. Urutan tindakannya selalu sama: pertama pisahkan perangkat keras Anda sendiri dari server milik orang lain, lalu pastikan waktu berhenti itu dengan sumber kedua, lalu pastikan stratum cadangan sudah mengambil alih beban. Pool cadangan di konfigurasi tidak berbiaya sepeser pun dan menghemat berjam-jam pendapatan, dan menuliskannya harus dilakukan pada hari yang tenang, bukan pada hari gangguan.