Sarado na ang Charles, pero nakaturo pa rin ang Mac mo sa 127.0.0.1

Nabigo ang isang application at ang VPN ang sinisisi, ngunit hindi kailanman nakarating ang kahilingan sa tunnel. Kung sinasabi pa rin ng macOS sa application na iyon na gumamit ng lokal na proxy, ang unang hop ay 127.0.0.1 at walang nakikinig doon. Hindi laging nililinis ng pagsasara ng Charles ang system proxy setting na inilagay nito, kaya ang malusog na VPN ay nasa likod ng patay na socket. Narito ang pagkakasunod-sunod upang kumpirmahin iyon at ayusin lamang ang maling bahagi.

Ang unang hop ay ang Mac na ito, hindi ang server

Basahin ang address nang literal: 127.0.0.1 ay ang makina sa harap mo, at ang port ay ang kung saan naka-configure ang proxy tool na makinig. Kapag wala na ang listener na iyon, agad na nabigo ang koneksyon sa tinanggihang koneksyon sa halip na timeout, at iyon ang kapaki-pakinabang na palatandaan.

Ang VPN ay hindi gumagawa ng sarili nitong proxy setting, at hindi nito tinatanggal ang mga setting ng system. Ang dalawang configuration ay independyente, kaya ang tunnel ay maaaring perpekto at ang browser ay hindi pa rin magamit. Ang pagsasarili ring iyon ang dahilan kung bakit nananatili ang pagkabigo pagkatapos ng muling pagkonekta ng VPN, pag-reboot at bagong profile. Wala sa landas ng VPN ang kailanman humahawak sa proxy store.

Hakbang 1: basahin ang kasalukuyang estado ng proxy

Magsimula sa read-only na view, dahil sinasabi nito kung ano ang pinaniniwalaan ng system bago ito bigyang-kahulugan ng anumang application:

scutil --proxy

Tingnan ang HTTPEnable, HTTPProxy, HTTPPort, ang mga katumbas na HTTPS, at anumang ProxyAutoConfigEnable kasama ang URL nito. Ang naka-enable na proxy na may port na walang nakikinig ay ang pagkabigo mo. Ang PAC URL ay ang iba pang anyo: ang setting ay maaaring aktibo nang walang nakikitang manual na address, dahil pipiliin ng file ang proxy sa oras ng kahilingan.

Pagkatapos kumpirmahin ang parehong mga halaga sa System Settings, Network, ang serbisyong aktwal mong ginagamit, Details, Proxies. Ang GUI at ang command ay nagbabasa ng parehong tindahan, kaya ang hindi pagkakasundo ay nangangahulugang tumitingin ka sa ibang serbisyo.

Hakbang 2: alamin kung sino ang may-ari ng setting

Tatlong may-ari ang gumagawa ng estadong ito: isang proxy tool na nag-install ng helper at hindi naglinis, isang pinamamahalaang configuration profile mula sa iyong organisasyon, at isang manual na setting na idinagdag ng isang tao habang nagde-debug. Bawat isa ay may ibang tamang pag-aayos, at ang una lamang ang sa iyo na tanggalin nang basta-basta.

Idinodokumento ng Charles ang integration nito sa browser at system proxy, kasama ang macOS helper, kaya gamitin muna ang sarili nitong mga kontrol at daan ng pagsasara. Ang privileged helper ay umiiral upang baguhin ang configuration; hindi iyon dahilan upang bigyan ang walang kaugnayang software ng malawak na access sa makina.

Kung ang setting ay nagmula sa isang pinamamahalaang profile, ang lokal na pag-disable ay maaaring mabigo o maibalik sa susunod na check-in. Ituring ito bilang tanong ng patakaran para sa may-ari ng profile, hindi bilang lokal na bug.

Hakbang 3: baguhin ang pinakamakitid na bagay

I-disable ang partikular na hindi kailangang entry para sa partikular na serbisyo. Huwag i-toggle ang bawat serbisyo at huwag i-clear ang buong panel ng proxy, dahil ang serbisyo ng VPN at ang pinagbabatayan na serbisyo ng Wi-Fi ay may magkahiwalay na setting at ang isa sa kanila ay maaaring tama.

Kung sadyang kailangan ang proxy, simulan ang aprubadong listener nito sa halip na tanggalin ang patakaran. Mahalaga ang pagkakaibang iyon sa mga organisasyon kung saan ang proxy ang tanging ruta sa internet at ang VPN ay pangalawang, mas makitid na ruta.

Subukan muli ang isang bagong kahilingan mula sa apektadong application. Ang ilang application ay nagbabasa ng proxy nang isang beses sa paglulunsad, kaya ang paglabas at muling pagbubukas ay bahagi ng pagsubok at hindi pamahiin.

Hakbang 4: kung wala na ang proxy at nabigo pa rin

Kung gayon, may ibang problema ka, at ang bagong error ang kapaki-pakinabang na ebidensya. Ang resolusyon ng pangalan, Pagruruta ng VPN, pagtitiwala sa TLS at awtorisasyon ng application ay apat na magkahiwalay na pagsusuri, at bawat isa ay gumagawa ng makikilalang pagkabigo.

Ilayo ang pagtitiwala sa sertipiko sa pag-aayos na ito. Ang pagtanggal ng pinagkakatiwalaang root o pagpapahina ng validation ng server ay hindi nag-aayos ng patay na proxy socket, at nag-iiwan ito sa iyo ng dalawang pagbabago at isang orihinal na depekto. Kung ang corporate proxy ay nagsisiyasat ng TLS, iyon ay sinadyang disenyo na may sariling pangangailangan sa pagtitiwala, hindi isang side effect na dapat i-undo. Tanungin ang team na may-ari ng proxy bago mo hawakan ang isang sertipiko, dahil ang sagot nila ay tungkol sa patakaran at ang sa iyo ay tungkol sa isang bigong kahilingan.

Isulat ang rollback bago ka magsimula: itala ang eksaktong mga halaga ng proxy na nakita mo, upang ang pagpapanumbalik ay isang kopya at hindi pagsasanay sa memorya. Ang dokumentasyon ng configuration ng proxy ng Charles ay naglalarawan ng integration at ng gawi nito sa pagsasara para sa bersyong pinapatakbo mo.

Sa susunod na mabigo ang isang app sa VPN, tingnan ang unang hop bago ang tunnel. Isang command lang ang halaga nito at inaalis ang isang buong kategorya ng maling diagnosis.