Pemeriksaan Koneksi Terputus Jarak Jauh Claude Code: Gejala, Kriteria, dan Solusi untuk Enam Jenis Putus

Menjalankan Claude Code dari jarak jauh, yang paling menyebalkan bukanlah tidak bisa terhubung, melainkan sudah terhubung lalu putus lagi, dan penyebab putusnya setiap kali berbeda-beda.

Kata "putus koneksi" sebenarnya menutupi enam jenis gangguan yang sama sekali berbeda. Gejalanya masing-masing memiliki ciri khas, dan cara perbaikannya pun tidak saling terkait—memperlakukan kegagalan koneksi panjang akibat perpindahan jaringan sebagai masalah tidur mesin, mematikan sleep pun tidak akan membantu; menganggap koneksi half-open sebagai jaringan yang buruk lalu menunggu, sampai pagi pun tidak akan sembuh sendiri.

Artikel ini menelusuri penyebab berdasarkan gejala yang benar-benar Anda lihat: untuk setiap jenis putus koneksi, dijelaskan gejalanya, cara memastikannya, serta solusi yang sesuai. Jika ingin langsung bertindak, lompat ke bagian daftar pemeriksaan di akhir.

Artikel ini hanya membahas pemeriksaan koneksi terputus. Cara menyiapkan akses jarak jauh lihat 《Akses Jarak Jauh Claude Code: Kendalikan Sesi dari Mana Saja Tanpa Perangkat Lokal》, cara penggunaan di ponsel lihat 《Menghubungkan Ponsel ke Claude Code: Lihat Sesi dan Setujui Alat di iOS Kapan Saja》.

Kenali Dulu Gejalanya: Tipe Mana yang Anda Lihat

Koneksi jarak jauh terdiri dari dua sisi: mesin pengembangan yang menjalankan Claude Code ←→ perangkat tampilan di tangan Anda. Masalah di salah satu sisi akan tampak sebagai "putus", tetapi gejalanya berbeda:

Gejala yang Anda lihat	Kemungkinan besar	Lompat ke
Sesi tiba-tiba berhenti, setelah menyambung ulang ternyata progres juga berhenti di momen itu	Mesin pengembangan tidur / layar terkunci	§1
Putus tepat saat masuk lift, pindah ke 4G, ganti WiFi	Koneksi panjang diputus paksa	§2
Begitu terminal lokal ditutup, atau perangkat lokal tidur, koneksi jarak jauh langsung ikut putus	Kendala keras dari solusi berbasis mirroring layar	§3
Menampilkan online, tetapi pesan tidak kunjung sampai, tanpa error apa pun	Koneksi half-open	§4
Bisa menyambung ulang, tetapi yang terhubung kembali adalah sesi kosong / pesan selama putus hilang	Sambungan ulang tidak kembali ke sesi asli	§5
Setelah beberapa jam baru tersambung lagi, sesi hilang	Proses didaur ulang, dan tidak ada cold recovery	§6

Yang paling mudah salah diagnosa adalah tipe keempat: tidak ada error. Status koneksi hijau, pesan terkirim, tetapi tidak pernah ada balasan—lebih sulit dilacak daripada putus total, karena semua indikator memberi tahu Anda "semuanya normal".

1. Mesin Pengembangan Tidur / Layar Terkunci / Layar Ditutup

Gejala: Sesi berhenti total pada suatu saat. Setelah menyambung ulang, progres masih berhenti di momen putus, tidak maju selangkah pun.

Mengapa: Banyak orang mengira "mesin pengembangan saya selalu menyala", tetapi sistem yang tidur, sleep karena layar ditutup, atau layar terkunci terjadwal semuanya akan menangguhkan atau langsung mematikan proses Claude Code. Dari sisi perangkat tampilan, yang terlihat adalah "tiba-tiba berhenti".

Cara memastikan: Kembali ke mesin pengembangan dan periksa apakah proses itu masih ada, dan apakah log sistem mencatat ada sleep. Jika proses masih ada tetapi timestamp berhenti di waktu putus, kemungkinan besar inilah penyebabnya.

Solusi: Atur rencana daya mesin pengembangan menjadi "jangan tidur / jangan sleep saat layar ditutup". Ini satu-satunya cara yang menyelesaikan akar masalah—solusi jarak jauh mana pun tidak bisa menyelamatkan mesin yang sudah tertidur.

2. Koneksi Panjang Terputus Akibat Perpindahan Jaringan

Gejala: Putus pada momen yang sangat jelas—masuk lift, WiFi berpindah ke 4G, broadband rumah melakukan dial ulang di tengah malam.

Mengapa: Sinkronisasi real-time jarak jauh bergantung pada satu koneksi panjang (WebSocket / SSH). Begitu IP berubah, koneksi itu langsung mati, tanpa ada ruang negosiasi.

Cara memastikan: Jika waktu putus koneksi bertepatan dengan waktu perpindahan jaringan Anda, itulah penyebabnya.

Solusi: Jenis ini tidak bisa dihindari, hanya bisa ditangani dengan sambungan ulang otomatis + backoff (1s→2s→5s…, hindari langsung menyerang setelah putus). SSH mentah tidak punya kemampuan ini; putus ya putus, harus disambungkan manual. Ini adalah syarat wajib saat memilih solusi.

3. Solusi Berbasis Mirroring Layar: Perangkat Lokal Harus Terbuka di Foreground

Gejala: Begitu terminal lokal ditutup, atau perangkat lokal tidur, di sisi ponsel langsung ikut putus. Bukan timeout perlahan, melainkan sinkronisasi gagal.

Mengapa: Remote Control resmi dari Anthropic adalah memproyeksikan sesi yang sedang berjalan di perangkat lokal Anda ke ponsel/browser. Prasyaratnya adalah Claude Code di perangkat lokal tetap berjalan di foreground dan perangkat lokal tetap online. Begitu perangkat lokal mati, sisi jarak jauh tidak punya siklus hidup mandiri untuk diikuti.

Cara memastikan: Tutup jendela terminal lokal, lihat apakah koneksi jarak jauh putus pada detik yang sama. Jika ya, Anda menggunakan solusi berbasis mirroring layar.

Solusi: Ganti ke arsitektur layanan daemon yang menetap di sisi mesin pengembangan—sisi yang menjalankan sesi dijadikan layanan latar belakang yang berjalan otomatis saat boot, hidup independen dari perangkat tampilan Anda. Meskipun perangkat tampilan dimatikan, diganti, atau putus, sesi tetap berjalan di mesin pengembangan. Inilah perbedaan mendasar antara "mirroring layar" dan "layanan menetap", bukan sesuatu yang bisa diatur melalui parameter.

4. Koneksi Setengah Mati (Half-Open): Jenis yang Paling Sulit Ditemukan

Gejala: Menampilkan online, pesan tidak berbalas, dan tidak ada error. Bisa macet beberapa menit, atau macet terus sampai Anda menyambungkan ulang secara manual.

Mengapa: Saat jaringan terputus secara diam-diam (entri NAT timeout, perangkat perantara kehilangan status, sinyal lemah hingga hanya paket yang hilang tetapi koneksi tidak putus), kedua ujung TCP mungkin sama-sama mengira masih terhubung, padahal data tidak akan pernah sampai lagi. Tanpa heartbeat, kedua belah pihak akan terus mempertahankan ilusi ini.

Cara memastikan: Status koneksi tampak normal, tetapi pesan yang dikirim tidak mendapat konfirmasi terkirim maupun error; setelah Anda memutus dan menyambungkan ulang secara manual, langsung pulih—itulah penyebabnya.

Solusi: Di atas koneksi perlu dijalankan heartbeat (keepalive ping): jika dalam waktu yang disepakati tidak ada respons dari lawan, maka koneksi tersebut dianggap half-open, lalu putus dan sambungkan ulang secara proaktif, bukan menunggu dengan pasif. Kriterianya harus "tidak menerima respons", bukan "tidak ada error"—koneksi half-open tidak pernah melaporkan error.

5. Sambungan Ulang Tidak Kembali ke Sesi Asli / Pesan Hilang

Gejala: Setelah putus bisa menyambung ulang, tetapi yang terhubung hanyalah sesi kosong, atau pesan yang dikirim lawan selama putus semuanya hilang.

Mengapa: Sambungan ulang hanya membuat koneksi baru, tidak men-subscribe kembali koneksi ke sesi asli; pesan selama putus juga tidak di-cache untuk Anda.

Cara memastikan: Setelah menyambung ulang, ID sesi berubah, atau riwayat hanya dimulai dari saat penyambungan ulang.

Solusi: Pilih solusi yang dapat secara otomatis berlangganan kembali ke sesi asli setelah sambungan ulang, serta memutar ulang riwayat selama putus. Hanya bisa menyambung ulang tanpa bisa kembali ke sesi, sama saja sia-sia.

6. Proses Sesi Didaur Ulang, dan Tidak Ada Cold Recovery

Gejala: Putus dan sambung ulang dalam waktu singkat berjalan normal, tetapi setelah beberapa jam kemudian kembali, sesi sudah hilang.

Mengapa: Proses sesi yang idle dalam waktu lama bisa didaur ulang, dan daemon itu sendiri mungkin sudah dimulai ulang (upgrade, diangkat setelah crash). Status sesi di memori ikut hilang.

Cara memastikan: Hanya muncul setelah putus lama, tidak muncul saat putus singkat.

Solusi: Diperlukan kemampuan cold recovery—status sesi disimpan ke disk, dan meskipun proses hilang, konteks bisa dipulihkan dari disk. Idealnya, ketika Anda mengirim satu pesan, sesi otomatis pulih dan berlanjut, tanpa Anda sadari.

Daftar Pemeriksaan (Bisa Diikuti oleh Solusi Apa Pun)

Ikuti urutannya, setiap langkah bisa diverifikasi/disangkal secara independen:

1. Apakah mesin yang menjalankan sesi tidur / layar terkunci? → Matikan sleep otomatis, jangan sleep saat layar ditutup. (§1)
2. Apakah waktu putus koneksi bertepatan dengan waktu perpindahan jaringan Anda? → Butuh solusi dengan sambungan ulang otomatis + backoff, jangan andalkan SSH mentah. (§2)
3. Saat terminal lokal ditutup, apakah koneksi jarak jauh langsung putus? → Ini kendala keras dari solusi mirroring layar, harus beralih ke arsitektur daemon menetap. (§3)
4. Macet di kondisi "menampilkan online tetapi pesan tidak berbalas"? → Koneksi half-open, hanya deteksi heartbeat yang bisa menyelamatkannya secara otomatis. (§4)
5. Setelah sambungan ulang sesi kosong / pesan berkurang? → Butuh "kembali ke sesi asli + putar ulang riwayat". (§5)
6. Sesi hanya hilang setelah putus lama? → Butuh penyimpanan ke disk + cold recovery. (§6)

Menerapkannya ke Solusi Spesifik

Dari enam poin di atas, hanya poin 1 yang merupakan masalah pengaturan mesin Anda sendiri; lima poin lainnya semuanya ditentukan oleh arsitektur—sudah terkunci saat pemilihan solusi, dan setelah masalah muncul, penyesuaian parameter tidak akan menyelamatkannya.

Solusi jarak jauh yang tidak mudah putus perlu memiliki semuanya sekaligus: proses daemon menetap di sisi mesin pengembangan (mengatasi risiko sisa di §1 dan §3), sambungan ulang otomatis + backoff (§2), deteksi heartbeat (§4), sambungan ulang kembali ke sesi asli + putar ulang riwayat (§5), dan cold recovery dari disk (§6).

Paket PandaNpc + pandapaw ini dirancang mengikuti keenam poin itu satu per satu: pandapaw didaftarkan di mesin pengembangan sebagai proses daemon menetap yang berjalan otomatis saat boot (bukan jendela terminal yang harus Anda buka manual; jika crash, otomatis diangkat kembali); perangkat tampilan menyambung ulang otomatis dengan backoff; di atas koneksi berjalan heartbeat, jika tidak ada respons maka dianggap half-open dan menyambung ulang secara proaktif; setelah sambungan ulang, otomatis berlangganan kembali ke sesi asli dan memutar ulang riwayat selama putus; bahkan jika proses sesi didaur ulang, mengirim satu pesan saja akan memulihkan sesi dari disk secara cold recovery.

Untuk cara instalasi dan koneksi, lihat 《Akses Jarak Jauh Claude Code》; untuk melihat sesi dan persetujuan alat di ponsel, lihat 《Menghubungkan Ponsel ke Claude Code》.

Satu Jebakan Tambahan: Hati-hati dengan Penagihan saat Menjalankan dari Jarak Jauh

Saat memeriksa koneksi terputus, Anda mungkin dengan mudah mengganti ke claude -p (mode headless), tetapi mulai 15 Juni 2026 Anthropic mengubah skema penagihan—headless tidak lagi menggunakan kuota langganan, melainkan memakan kredit SDK bulanan kecil, dan setelah habis ditagih berdasarkan API; pemakaian berat sangat mudah membengkak. Mode interaktif (claude REPL) tetap menggunakan kuota langganan. Saat mengganti solusi untuk memeriksa koneksi terputus, pastikan jangan ikut mengganti mode penagihan.