브라우저 프록시 확장 프로그램에서 가장 흔히 걸리는 함정은 적용 범위입니다. 확장 프로그램은 브라우저 트래픽만 담당하며, 규칙이 맞지 않으면 직접 연결로 빠질 수 있습니다. 이 글은 용도별로 확장 프로그램을 분류하고 프로토콜, 인증, 권한, 유지보수 상태 같은 평가 기준을 정리한 뒤, 출구 IP와 WebRTC 누출을 확인하는 자체 점검 절차를 제시합니다.
브라우저 프록시 확장 프로그램에는 자주 간과되는 경계가 있습니다. 확장 프로그램이 담당하는 것은 브라우저가 보내는 요청뿐입니다. 시스템 업데이트, 데스크톱 클라이언트, 다른 앱의 트래픽은 그대로 원래 경로를 따릅니다. 무엇을 프록시로 보낼지 먼저 정리한 다음 도구를 고르면 이후의 문제 진단이 훨씬 수월해집니다.
먼저 용도에 따라 세 갈래로 나누기
가장 흔한 요구는 사이트별 전환입니다. 일부 도메인만 프록시를 거치게 하고 나머지는 그대로 직접 연결합니다. 이 경우는 규칙 목록으로 제어하며, 확장 프로그램의 가치는 빠른 전환과 도메인 단위 분기에 있습니다.
두 번째는 전역 프록시로, 브라우저의 모든 트래픽이 하나의 출구로 나갑니다. 설정은 가장 간단하지만 대가는 분명합니다. 출구가 죽으면 브라우저는 사실상 오프라인이 되어 일상적인 사용이 불안정해집니다.
세 번째는 환경에 묶는 방식으로, 브라우저 프로필마다 출구를 고정하고 프로필끼리 서로 영향을 주지 않습니다. 여러 계정이나 여러 프로젝트를 병행할 때 쓰는 접근이며, 여기서 확장 프로그램은 보조적인 역할에 그칩니다. 출구 자체는 보통 더 낮은 계층에서 설정하기 때문입니다.
확장 프로그램을 평가할 때 볼 항목
프로토콜 지원이 첫 번째입니다. HTTP와 HTTPS 프록시는 TCP만 처리하고, SOCKS5는 더 범용적이지만 UDP 지원은 구현에 따라 달라지며, 많은 확장 프로그램이 UDP를 그대로 통과시키거나 아예 버립니다. 이 점은 나중에 중요해집니다. WebRTC가 새는지와 직결되기 때문입니다.
인증 방식도 자세히 봐야 합니다. 사용자 이름과 비밀번호 인증은 편리하지만, 확장 프로그램에 저장된 자격 증명은 로컬에 평문이나 약한 암호화로 남아 있어 컴퓨터를 함께 쓰는 다른 사람이 읽을 수 있습니다. IP 허용 목록 인증은 확장 프로그램에 아무것도 저장하지 않지만, 네트워크를 바꿀 때마다 목록을 다시 추가해야 합니다.
적용 범위가 가장 문제가 되기 쉬운 지점입니다. 규칙 모드에서 어떤 규칙에도 맞지 않는 도메인은 기본적으로 직접 연결로 나가며, 페이지가 실제로 어떤 도메인을 요청하는지는 알지 못할 수 있습니다. HTTPS 사이트는 연결이 맺어진 뒤에는 확장 프로그램이 도메인만 볼 수 있고 구체적인 경로는 볼 수 없으므로, 경로로 분기한다는 발상은 사실상 성립하지 않습니다.
권한 범위도 한 번 살펴봐야 합니다. 프록시 확장 프로그램이 모든 웹사이트의 데이터 읽기, 탭 정보, 클립보드 같은 권한까지 요청한다면, 그 권한이 내세우는 기능과 관련이 있는지 물어야 합니다. 브라우저 확장 프로그램의 매니페스트 버전 상향도 사용 가능한 인터페이스를 조이고 있어, 일부 오래된 확장 프로그램은 구조를 바꿔야 했습니다.
유지보수 활발함은 변경 기록의 양이 아니라 상위 프로젝트의 변화를 따라가는 사람이 있는지로 봅니다. 프록시 확장 프로그램 가운데 Proxy SwitchyOmega의 스토어 버전은 내려갔고, 커뮤니티가 유지하는 포크(예를 들어 ZeroOmega 계열)가 이후 대응을 이어받았습니다. FoxyProxy 같은 확장 프로그램은 여러 브라우저용 버전이 있습니다. 이는 중립적인 예시일 뿐이며, 어느 것이 더 적합한지는 위 항목에 따라 달라집니다.
확장 프로그램이 덮지 못하는 트래픽
확장 프로그램을 설치하면 브라우저 자체는 프록시를 거치지만, 같은 컴퓨터의 다른 프로그램, 백그라운드 업데이트 서비스, 그리고 브라우저 내부에서 확장 프로그램의 요청 경로를 따르지 않는 일부 트래픽은 여전히 로컬 출구로 나갈 수 있습니다. 네트워크 일관성 점검을 확장 프로그램 패널만 보고 할 수는 없습니다. 완전한 격리는 시스템 프록시나 그보다 상위 계층에서 해결해야 합니다.
자체 점검: 출구 먼저, 그다음 누출
첫 단계는 출구 IP 확인입니다. 방문자 IP와 위치를 돌려주는 페이지를 몇 개 열고, 일반 창과 규칙에 맞는 탭에서 각각 한 번씩 확인해 결과가 같은지 비교합니다. 규칙에 프록시를 적었는데도 로컬 주소가 나온다면 규칙이 적용되지 않았거나 도메인이 맞지 않은 것입니다. 여러 사이트를 확인하면 일부 요청만 프록시를 거치는 경우도 찾아낼 수 있습니다.
두 번째 단계는 WebRTC 확인입니다. 전용 점검 페이지는 브라우저가 얻는 로컬 후보 주소와 공인 후보 주소를 나열합니다. 공인 후보에 프록시 출구가 아니라 실제 IP가 나타난다면 UDP가 프록시를 거치지 않는다는 뜻이며, 페이지 스크립트가 여전히 실제 네트워크 위치를 알아낼 수 있습니다.
세 번째 단계는 DNS 확인입니다. 이름 해석 서버의 위치와 출구의 위치가 너무 멀면 일부 사이트는 환경이 비정상이라고 판단합니다.
마지막 단계는 시크릿 창에서 다시 점검하는 것입니다. 많은 확장 프로그램은 기본적으로 시크릿 모드에서 동작하지 않으며 확장 프로그램 설정에서 직접 허용해야 합니다. 이 단계를 잊으면 완전히 잘못된 결론에 이릅니다.
점검 후 사용 방식을 결정
자체 점검 결과는 확장 프로그램의 설명보다 신뢰할 수 있습니다. 실제 출구, DNS 해석 위치, WebRTC 노출 상황이 맞춰진 뒤에 확장 프로그램을 계속 쓸지, 출구를 더 낮은 계층으로 내릴지 결정합니다. 여러 환경을 병행하는 상황에서는 여러 장비가 하나의 출구를 공유하기보다 각 환경에 독립된 출구를 두고 고정하는 편이 좋습니다.
