Halaman chat terbuka tetapi koneksi langsung gagal: dari mana memeriksanya

Buka panel jaringan sebelum memuat halaman chat, lalu cari permintaan yang membawa pesan dan bukan permintaan yang merender kerangka halaman. Dokumen, skrip, pertukaran saat masuk, dan transport chat bisa menuju host yang berbeda-beda. Sebagian besar laporan bahwa VPN merusak chat sebenarnya menggambarkan salah satu dari empat permintaan itu gagal. Amati berurutan dan jawabannya biasanya sudah terlihat dalam dua menit pertama.

Temukan permintaan yang membawa pesan

Saring menurut jenis setelah halaman selesai dimuat: WebSocket muncul sebagai entri tersendiri, event stream tetap terbuka dengan respons yang terus bertambah, dan long poll berulang pada interval tetap. Catat skema, host, port, dan status untuk entri yang membawa pembaruan. Perhatikan apakah koneksi dimulai sebelum atau sesudah masuk, karena transport yang dibuka sebelum autentikasi biasanya rancangan yang berbeda dari yang dibuka sesudahnya. Baca header permintaan untuk permintaan upgrade atau tipe konten yang diterima, karena header itu menunjukkan transport yang benar-benar dipilih halaman yang sedang dipasang.

Posting forum lama menjelaskan transport yang sudah ditinggalkan produk bertahun-tahun lalu, jadi percayai apa yang dicatat browser, bukan artikelnya. Jika entri itu sama sekali tidak ada, kode klien mungkin tidak pernah mencoba koneksi, yang menunjuk pada kegagalan skrip atau konfigurasi yang lebih awal. Halaman yang termuat hanya membuktikan dokumennya sampai, dan perbedaan itu menentukan apakah Anda memang sedang men-debug jaringan.

Penyiapan, pengiriman, dan masa hidup gagal dengan cara berbeda

WebSocket dibuka dengan upgrade HTTP yang dijawab status 101, dan setelah itu semuanya berupa pesan berbingkai, bukan pengambilan halaman; dua tahap itu RFC 6455 jaga tetap terpisah secara eksplisit. Event stream menjawab dengan tipe konten streaming dan menahan badan respons tetap terbuka. Keduanya bisa gagal terbuka, terbuka tetapi tidak mengirim apa pun, atau terbuka, mengirim, lalu mati diam-diam.

wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events

Tangkap kegagalan bermakna pertama sebelum Anda menyentuh profil, karena tiga waktu kejadian itu menunjuk lapisan yang berbeda. Jika handshake tidak pernah selesai, bandingkan dengan permintaan HTTPS biasa ke host yang sama untuk melihat apakah ada yang mencapainya sama sekali. Jika selesai tetapi tidak ada pesan yang datang, amati frame atau badan stream sementara seseorang mengirim pesan uji dari akun lain. Jika berhasil lalu berhenti, catat waktu tepatnya dan kode penutupan, karena pasangan itu menunjukkan ujung mana yang menyerah.

Kode 1006 berarti soket ditutup tanpa frame penutupan, dan begitulah middlebox atau batas waktu diam terlihat dari dalam browser. Heartbeat VPN tidak membuktikan bahwa sesi aplikasi di dalamnya masih hidup.

Host langsung adalah tujuan yang terpisah

Backend chat sering berada di nama hostnya sendiri, kadang di port berbeda atau di balik sertifikat terpisah. Tujuan itu membutuhkan resolusi, rute, dan perlakuan proxy sendiri, dan split tunnelling bisa menyertakan halaman sambil mengecualikan soket. Resolusi nama host langsung dari mesin klien dan pastikan ia menjawab dengan alamat yang Anda harapkan di jaringan itu. Periksa rantai sertifikat khusus untuk nama host itu, karena wildcard yang mencakup situs tidak selalu mencakup endpoint soket.

Jika ada proxy di jalur tersebut, pastikan proxy mengizinkan upgrade atau respons berumur panjang, bukan menampungnya di buffer. Proxy korporat yang menulis ulang HTML sering menangani upgrade WebSocket dengan buruk, sehingga halaman tampil sementara chat tidak pernah tersambung. Dua permintaan ke produk yang sama karena itu bukan dua permintaan ke host yang sama.

Perbaiki daftar tujuan, bukan pemeriksaan keamanan

Memperbaiki daftar tujuan adalah perubahan rute dan menjadi milik pemilik rute. Melonggarkan validasi sertifikat atau mencopot header Origin adalah perubahan keamanan dan menjadi milik pemilik kebijakan, yang jarang orang yang sedang men-debug tiket. Cara tercepat membuat koneksi tampak berhasil biasanya juga cara tercepat membuat insiden mungkin terjadi.

Tanyakan kepada pemilik aplikasi origin mana yang diterima backend sebelum mengubah apa pun, lalu sampaikan jawaban itu kepada yang mengendalikan proxy. Jika kesalahan sertifikat hanya muncul lewat terowongan, periksa perangkat yang menyeleksi lalu lintas itu, jangan memasang bypass.

Catat cukup banyak untuk diserahkan

Artefak yang berguna itu singkat: URL halaman, endpoint langsung, hasil handshake, waktu kegagalan pertama, dan apakah sambung ulang pernah dicoba. Tambahkan nama profil VPN dan jaringan yang Anda pakai, dan siapa pun yang membacanya dapat mereproduksi pengujian tanpa mengajukan enam pertanyaan. Sembunyikan cookie, header otorisasi, dan badan pesan, dan lebih baik sertakan tangkapan layar kolom waktu daripada ekspor arsip penuh. Frame dan arsip jaringan bisa memuat pesan pribadi dan token sesi, jadi periksa dulu sebelum melampirkan apa pun.

Jika kegagalannya penutupan senyap, sertakan kode penutupan dan interval diam sebelumnya, karena pasangan itu biasanya menunjukkan pemilik batas waktunya. Serahkan catatan itu kepada pemilik aplikasi atau gateway, jangan menebak nilai batas waktu sendiri. Jawaban mereka tentang perilaku keepalive yang didukung adalah jawaban yang menutup tiket.