Charles sudah ditutup, tetapi Mac Anda masih menunjuk ke 127.0.0.1

Sebuah aplikasi gagal dan VPN disalahkan, padahal permintaannya tidak pernah mencapai terowongan. Jika macOS masih menyuruh aplikasi itu memakai proxy lokal, lompatan pertama adalah 127.0.0.1 dan tidak ada yang mendengarkan di sana. Menutup Charles tidak selalu membersihkan pengaturan proxy sistem yang dipasangnya, jadi VPN yang sehat berada di balik soket mati. Berikut urutan untuk memastikannya dan hanya memperbaiki bagian yang salah.

Lompatan pertama adalah Mac ini, bukan server

Baca alamatnya secara harfiah: 127.0.0.1 adalah mesin di depan Anda, dan port-nya adalah yang dikonfigurasi untuk didengarkan oleh alat proxy. Ketika pendengar itu hilang, koneksi langsung gagal dengan koneksi ditolak alih-alih timeout, dan itulah petunjuk yang berguna.

VPN tidak membuat pengaturan proxy sendiri dan tidak menghapus pengaturan sistem. Kedua konfigurasi itu independen, karena itu terowongan bisa sempurna sementara peramban tetap tidak bisa dipakai. Kemandirian itu juga menjelaskan mengapa kegagalan bertahan setelah VPN disambungkan ulang, reboot, dan profil baru. Tidak ada apa pun di jalur VPN yang pernah menyentuh penyimpanan proxy.

Langkah 1: baca status proxy saat ini

Mulailah dengan tampilan hanya-baca, karena itu memberi tahu apa yang diyakini sistem sebelum aplikasi mana pun menafsirkannya:

scutil --proxy

Lihat HTTPEnable, HTTPProxy, HTTPPort, padanan HTTPS-nya, dan apa pun ProxyAutoConfigEnable beserta URL-nya. Proxy yang aktif pada port yang tidak didengarkan apa pun adalah kegagalan Anda. URL PAC adalah bentuk lainnya: pengaturan bisa aktif tanpa alamat manual yang terlihat, karena berkas itu memilih proxy pada saat permintaan.

Lalu pastikan nilai yang sama di Pengaturan Sistem, Jaringan, layanan yang benar-benar Anda pakai, Detail, Proxy. GUI dan perintah membaca penyimpanan yang sama, jadi ketidakcocokan berarti Anda melihat layanan lain.

Langkah 2: temukan siapa pemilik pengaturan itu

Tiga pemilik menghasilkan keadaan ini: alat proxy yang memasang helper dan tidak membersihkannya, profil konfigurasi terkelola dari organisasi Anda, dan pengaturan manual yang ditambahkan seseorang saat men-debug. Masing-masing punya perbaikan yang benar dan berbeda, dan hanya yang pertama boleh Anda hapus tanpa ragu.

Charles mendokumentasikan integrasi peramban dan proxy sistemnya, termasuk helper macOS, jadi pakai dulu kendali dan jalur mematikannya sendiri. Helper berhak istimewa ada untuk mengubah konfigurasi; itu bukan alasan memberi perangkat lunak tak terkait akses luas ke mesin.

Jika pengaturan berasal dari profil terkelola, menonaktifkannya secara lokal entah gagal atau dikembalikan pada pemeriksaan berikutnya. Perlakukan itu sebagai pertanyaan kebijakan bagi pemilik profil, bukan bug lokal.

Langkah 3: ubah hal yang paling sempit

Nonaktifkan entri tak diinginkan yang spesifik untuk layanan yang spesifik. Jangan mengalihkan setiap layanan dan jangan membersihkan seluruh panel proxy, karena layanan VPN dan layanan Wi-Fi di bawahnya menyimpan pengaturan terpisah dan salah satunya mungkin benar.

Jika proxy memang diperlukan dengan sengaja, jalankan pendengar yang disetujui alih-alih menghapus kebijakannya. Perbedaan itu penting di organisasi yang proxy-nya satu-satunya rute ke internet dan VPN adalah jalur kedua yang lebih sempit.

Coba ulang satu permintaan baru dari aplikasi yang terdampak. Sebagian aplikasi membaca proxy sekali saat diluncurkan, jadi menutup dan membukanya lagi adalah bagian dari uji, bukan takhayul.

Langkah 4: jika proxy sudah hilang dan masih gagal

Maka Anda punya masalah lain, dan galat baru itulah bukti yang berguna. Resolusi nama, perutean VPN, kepercayaan TLS, dan otorisasi aplikasi adalah empat pemeriksaan terpisah, dan masing-masing menghasilkan kegagalan yang bisa dibedakan.

Jauhkan kepercayaan sertifikat dari perbaikan ini. Menghapus akar tepercaya atau melemahkan validasi server tidak memperbaiki soket proxy yang mati dan meninggalkan Anda dengan dua perubahan dan satu kesalahan awal. Jika proxy korporat memeriksa TLS, itu rancangan sengaja dengan kebutuhan kepercayaannya sendiri, bukan efek samping yang harus dibatalkan. Tanyakan tim pemilik proxy sebelum menyentuh sertifikat, karena jawaban mereka soal kebijakan dan jawaban Anda soal satu permintaan yang gagal.

Tulis rencana pembatalan sebelum mulai: catat nilai proxy persis yang Anda temukan, agar pemulihan menjadi penyalinan, bukan latihan ingatan. Dokumentasi konfigurasi proxy Charles menjelaskan integrasi dan perilaku mematikannya untuk versi yang Anda jalankan.

Lain kali sebuah aplikasi gagal pada VPN, periksa lompatan pertama sebelum terowongan. Itu berbiaya satu perintah dan menyingkirkan satu kategori kesalahan diagnosis.