libproxy는 경로를 고르고, 연결은 클라이언트가 맺는다
libproxy 결과를 URL별 라우팅 후보로 사용하고, 검색이 애플리케이션의 소켓을 리디렉션한다고 기대하지 마세요.
libproxy가 프록시 URI를 반환했는데 다음 소켓이 직접 연결된다면 핸드오프를 확인하세요. libproxy는 정책을 검색하지만 애플리케이션이 여는 모든 소켓을 가로채지는 않습니다.
- 리소스를 질의합니다. 문서화된 libproxy 0.5 C API에서 프록시 팩토리를 만들고 실제 대상 URL을 요청하세요.
- 정렬된 후보를 해석합니다. HTTP, SOCKS, 직접 결과는 처리가 다릅니다. 선호 순서와 의도한 실패 정책을 유지하세요.
- 소비자를 구성합니다. 선택한 프록시 유형, 엔드포인트, 인증 방식을 이를 지원하는 전송 계층에 전달하세요. 원시 TCP 소켓은 반환된 URI에서 CONNECT나 SOCKS 협상을 얻지 못합니다.
하나의 답을 모든 대상의 경로로 저장하지 말고, 첫 프록시가 한 번 실패했다고 직접 라우팅을 영구화하지 마세요.
HTTP 클라이언트가 이미 시스템 프록시나 PAC 검색을 통합한다면 선택 소유자를 하나로 정하세요. 독립적인 선택기 두 개에 래퍼가 하나 더해지면 어느 정책도 의도하지 않은 경로가 생길 수 있습니다.
네이티브 코드에서는 설치된 API의 팩토리와 결과 메모리 수명 주기를 따르세요. 팩토리를 재사용하면 유용한 검색 상태를 유지할 수 있지만, 대상마다 질의는 여전히 필요합니다. 선택은 연결 결과와 별도로 기록하세요. 반환된 URI는 인증, 이름 해석, 이후 접근의 성공을 증명하지 않습니다.