Kapag pumalya ang proxy connection, suriin ito sa tatlong layer: tiyaking nagbago ang IP at tama ang exit location, ihiwalay ang DNS, timeout, at certificate errors, saka beripikahin ang authentication, port, at protocol.
Naka-configure na ang proxy at tama ang username at password, pero connection failure pa rin ang lumalabas sa check. Marami ang agad kumokontak sa proxy provider, nagpapalit ng node, nagbabago ng port, o kinukulit ang support. Kadalasan ay mababa ang efficiency nito dahil puwedeng nasa kahit anong bahagi ng buong connection path ang sanhi, at isa lang ang proxy sa mga bahagi nito.
Sa halip na sumubok nang paisa-isa nang walang sistema, gumamit ng pare-parehong pagkakasunod mula labas papasok: tiyakin muna kung talagang gumagana ang exit, saka tingnan kung maayos ang network path, at pagkatapos lamang suriin ang authentication at protocol sa application layer. Sa tatlong layer na ito, matutukoy ang karamihan ng problema.
Talaga bang gumagana ang exit?
Madaling malampasan ang hakbang na ito dahil mukhang matagumpay ang configuration. Pero magkaiba ang matagumpay na configuration at ang trapikong talagang dumadaan sa proxy.
Dalawang bagay ang tingnan. Una, nagbago ba ang IP? Itala ang public IP kapag walang proxy, i-on ang proxy, at tingnan muli. Kung pareho ang dalawa, hindi talaga lumalabas sa proxy ang traffic at masasayang lang ang susunod na troubleshooting. Ikalawa, tama ba ang lokasyon? Karaniwang ibinibigay sa proxy details ang bansa, rehiyon, state o province, lungsod, latitude at longitude na may anim na decimal place, at postal code. Ihambing ang mga ito sa rehiyong binili. Babala rin kung malinaw na hindi tugma ang system time zone sa exit region.
Kapag hindi gumagana ang exit, madalas nasa natirang local settings ang dahilan at hindi sa provider. Kung hindi nalinis nang maayos ng dating network tool ang settings nang isinara ito, maaaring maiwan sa system ang environment variables gaya ng HTTP_PROXY at HTTPS_PROXY, o manatiling naka-on ang Web Proxy o SOCKS Proxy sa macOS. Sa ganitong sitwasyon, iniisip ng client na sumusunod ito sa system proxy pero talagang nilalampasan ito ng requests. Mas kapaki-pakinabang kadalasan na linisin ang mga natirang setting at muling mag-test kaysa i-configure ulit ang buong proxy.
Tatlong karaniwang error sa network path
Kapag kumpirmadong maayos ang exit, tingnan kung talagang nakararating sa target ang request.
DNS resolution ang unang posibleng bottleneck. Maaaring mag-fail ang resolution o magkaroon ng malinaw na maling resulta, gaya ng domain na dapat tumuro sa target service pero napupunta sa kakaibang address. Subukang gumamit ng public DNS o i-clear ang local DNS cache, saka tingnan kung bumalik sa normal.
Connection timeout ang ikalawang uri. Kapag bina-block ng firewall o security software ang port, karaniwang patuloy lang itong naglo-load at pagkatapos ay nagti-timeout. Suriin ang port allow rules at kung may sariling restriction ang environment, gaya ng corporate network o public Wi-Fi. May mabilis na test: kumonekta nang direkta nang walang proxy. Kung wala ring mabuksang website, nasa basic network ang problema at hindi sa proxy. I-restart ang router o lumipat sa mobile hotspot para makumpirma.
Dapat hiwalay na suriin ang certificate errors. Kapag lumabas ang untrusted certificate o handshake failure, karaniwang unang hinala ang pag-decrypt ng traffic o pagpapalit ng certificate. Posible iyon, pero may mas hindi halatang dahilan: mali ang oras ng device. Maraming authentication at session mechanism ang umaasa sa timestamp. Kapag higit sa 5 minuto ang agwat ng local time at server time, maaaring bumagsak ang signature validation at tanggihan ang connection; sa HTTPS, lumalabas ito bilang certificate validation failure. Kapag may certificate error, tingnan din ang status ng system time synchronization. Kung may problema, i-on ang automatic synchronization, itama agad ang oras, i-restart ang client, at subukan muli.
Huwag pagpalitin ang authentication at protocol
Kung naaabot ang proxy server pero hindi pa rin gumagana ang traffic, malamang nasa application layer ang problema.
Pinakakaraniwan ang authentication information. Dapat tugma ang proxy username, password, at authentication method sa ibinigay ng provider; karaniwan din ang napalitang password na hindi na-update sa configuration. Sa manual configuration, tiyakin ding ang port na inilagay ay kapareho ng port na pinakikinggan ng proxy tool mismo. Maaaring magkamukha ang mga numero, pero kapag mali ang port, hindi talaga makakonekta.
Protocol mismatch ang ikalawang uri. Hindi puwedeng paghalu-haluin ang HTTP, HTTPS, at SOCKS5: kung SOCKS5 ang ibinigay ng provider pero HTTP ang inilagay sa configuration, tiyak na mabibigo ang check. Kumpirmahin din kung pinapayagan ng proxy ang target site at target port, dahil may ilang proxy na naghihigpit sa target o protocol.
Pinakamabilis na paraan para malaman kung node o configuration ang problema ang pagsubok ng ibang node. Kung gumana ang kapalit, nasa orihinal na node ang problema. Kung hindi pa rin gumana, bumalik sa configuration at network path. Huwag paulit-ulit baguhin ang maraming parameter nang sabay; isang variable lang kada pagbabago at itala ang resulta, kung hindi ay maaaring matakpan ng sarili mong pagbabago ang tunay na sanhi.
Ang connected ay hindi awtomatikong nangangahulugang usable ang environment
May isa pang karaniwang bitag. Maaaring normal ang proxy connection pero madalas pa ring ma-trigger ang risk controls ng account. Ang problema ay maaaring hindi kung nakakonekta, kundi kung ang exit ay mukhang normal na user environment.
Pareho pa rin ang dapat suriin: tugma ba ang exit location sa registration region ng account; makatwiran ba ang IP type, dahil maaaring magkaiba ang trust level ng platform para sa data center IP at residential IP; at na-flag na ba dati ng target site ang IP na ito? Kung maraming abnormal activity ang dating dumaan sa parehong IP, maaaring maapektuhan ang mga susunod na gumagamit. Kapag pumasa na ang connection test, maglaan pa ng ilang minuto para tingnan ang kalinisan ng exit.
Kung maraming environment ang tumatakbo sa iisang device, mas mainam na one-to-one ang exit: bawat environment ay may sariling exit. Mas madaling ihiwalay ang problema, at kung ma-flag ang isang exit, ang katumbas na environment lang ang maaapektuhan sa halip na lahat. Sa multi-environment management, hiwalay na kino-configure at ini-isolate ng PurpleMark ang exit para sa bawat environment dahil ito mismo ang lohika nito.
Ang mga paraang ito sa troubleshooting ay para lamang sa teknikal na talakayan. Gamitin ang kaugnay na tools at services alinsunod sa naaangkop na batas at regulasyon.
