프록시가 한 웹사이트에서는 되고 다른 곳에서는 안 되는 이유
정상적인 프록시 연결을 목적지 제한, 포트 규칙, TLS 오류, HTTP 응답과 구분하세요.
한 웹사이트는 되고 다른 곳은 안 될 때 프록시 설정을 그대로 두세요. 요청 간 차이는 유용한 증거입니다. 엔드포인트를 바로 바꾸면 그 증거를 잃습니다.
HTTP 프록시를 통한 HTTPS에서는 클라이언트 추적에서 CONNECT 응답, 목적지와의 TLS, 웹사이트의 최종 HTTP 응답을 구분하세요.
| 관찰된 실패 | 확인할 내용 |
|---|---|
| 프록시 응답 없음 | 프록시 연결과 경로. 이전에 사이트 접속에 성공했다고 현재 사용 가능하다는 뜻은 아닙니다. |
| 특정 목적지의 CONNECT 거부 | 허용된 목적지/포트 정책과 프록시 네트워크에서의 도달 가능성. |
| 터널 수락 후 인증서 검증 실패 | 보고된 인증서 오류: 만료, 호스트 이름, 로컬 시계, 신뢰 설정 또는 관리되는 가로채기. |
| TLS 검증 후 웹사이트 403 | 웹사이트의 접근 규칙, 계정 상태, 필수 쿠키와 권한. |
| 웹사이트 429 | 공개된 요청 빈도 제한. 다른 사용자의 활동도 공유 출구에 귀속될 수 있습니다. |
오류 페이지를 누가 만들었는지 확인하세요. 중간 시스템이 403이나 다른 HTTP 오류를 반환할 수 있으며, 코드만으로 발생 위치를 알 수 없습니다. 성공처럼 보이는 요청이 보안 연결 실패를 감추지 않도록 TLS 검증을 켜 두세요.
목적지마다 프록시 핸드셰이크 결과, TLS 결과, 최종 상태를 기록하세요. 직접 관리하는 일반 목적지를 기준으로 포함하세요. 엔드포인트가 그곳에는 도달하지만 특정 웹사이트가 출구 주소를 계속 거부한다면 사이트 요구사항을 조사하거나 다른 허용된 경로를 쓰세요. 프록시를 바꿔도 빠진 인증이나 접근 권한을 충족할 수는 없습니다.