Kvifor ein proxy verkar på éin nettstad, men ikkje ein annan
Skil eit fungerande proxysamband frå målavgrensingar, portreglar, TLS-feil og HTTP-svar.
Lat proxykonfigurasjonen vere uendra når éin nettstad verkar og ein annan ikkje gjer det. Skilnaden mellom førespurnadene er nyttig bevismateriale; byter du endepunkt straks, mistar du det.
For HTTPS gjennom ein HTTP-proxy må du i klientsporet skilje mellom CONNECT-svaret, TLS med målet og det endelege HTTP-svaret frå nettstaden:
| Observert feil | Kva du bør undersøkje |
|---|---|
| Ikkje svar frå proxyen | Proxysambandet og ruta. Ein nettstad som verka tidlegare, provar ikkje at proxyen er tilgjengeleg no. |
| CONNECT avvist for eitt mål | Reglane for tillatne mål/portar og tilgjenge frå proxyen sitt nettverk. |
| Tunnel godteken, sertifikatkontroll feilar | Den rapporterte sertifikatfeilen: utløp, vertsnamn, lokal klokke, tillitsoppsett eller administrert avskjering. |
| Verifisert TLS etterfølgt av 403 frå nettstaden | Tilgangsreglane på nettstaden, kontostatus, nødvendige informasjonskapslar og løyve. |
| 429 frå nettstaden | Publiserte frekvensgrenser. Andre brukarar kan bidra til aktivitet som vert tilskriven ein delt utgang. |
Sjå kven som laga feilsida. Eit mellomledd kan returnere 403 eller ein annan HTTP-feil; talet åleine viser ikkje kvar han oppstod. Hald TLS-kontroll aktivert, slik at ein tilsynelatande vellukka førespurnad ikkje skjuler ein feil i det sikre sambandet.
Noter for kvart mål resultatet av proxyhandtrykket, TLS-resultatet og den endelege statusen. Ta med eit vanleg mål du kontrollerer som referanse. Når endepunktet når dette, men éin nettstad stadig avviser utgangsadressa, undersøk krava frå nettstaden eller bruk ei anna tillaten rute. Å byte proxy kan ikkje erstatte manglande autentisering eller tilgangsløyve.