브라우저 프로필별 프록시: DNS, 인증, 장애 동작

이 가이드는 Chromium에 문서화된 네트워크 동작을 기준으로 사용합니다. 다른 브라우저와 제품은 다른 방식을 선택할 수 있고 브라우저 관리자는 Chromium 주위에 로컬 네트워크 중개자를 추가할 수 있습니다. 실제로 운영하는 정확한 빌드의 동작을 확인하세요.

서로 독립적인 네 가지 질문부터 시작하기

프록시 레코드에는 일반적으로 스킴, 엔드포인트, 포트, 경우에 따라 인증 참조가 들어 있습니다. 이 레코드에도 별도의 정책 질문 네 가지가 남습니다.

1. 적용 범위: 어떤 브라우저 요청과 프로토콜이 이 프록시에 할당되나요?
2. 이름 확인: 기기와 프록시 중 어느 쪽이 대상 호스트 이름을 확인하나요?
3. 인증: 어떤 클라이언트 및 프록시 스킴 조합이 작동하며 자격 증명은 어디에 저장되나요?
4. 장애: 연결 오류가 발생하면 요청을 중단하나요, 다른 프록시를 시도하나요, 직접 경로를 사용하나요?

이를 하나의 “프록시 켜짐” 스위치로 취급하면 대부분의 예상 밖 동작이 생깁니다. Chromium은 프록시 선택을 URL 수준 결정으로 설명합니다. URL에서 대상 이름을 확인하기도 전에 순서가 있는 프록시 선택지 목록이 만들어집니다. 우회 및 대체 경로 규칙도 이 결정의 일부입니다.

프로필별 프록시의 적용 범위

Google의 ProxySettings 정책은 Chrome 프로필 수준에 적용됩니다. 명시적인 우회 및 PAC 필수 필드와 함께 직접, 시스템, 자동 감지, 고정 서버 또는 PAC 스크립트 모드를 선택할 수 있습니다.

이 경계는 VPN이나 운영체제 네트워크 네임스페이스보다 좁습니다. 브라우저 네트워크 컨텍스트가 처리하는 요청을 통제합니다. 다음 항목을 자동으로 통제하지는 않습니다.

• 데스크톱 관리자의 자체 API 호출
• 별도 프로세스 애플리케이션 또는 브라우저 업데이터
• 운영체제 DNS 및 연결 검사
• 다운로드 파일에서 실행한 다른 애플리케이션
• 확장 프로그램의 별도 네이티브 도우미
• 암묵적인 루프백 우회를 통해 접근한 로컬 서비스
• 선택한 프록시 경로가 전달할 수 없는 프로토콜을 쓰는 트래픽

일부 구성 요소에는 자체 프록시 지원이 있을 수 있습니다. 해당 지원은 별도로 지정하고 테스트해야 합니다. “프로필 트래픽이 이 프록시를 사용한다”는 브라우저 제품의 진술은 기기 전체 라우팅을 암시하지 말고 포함되는 프로세스와 프로토콜을 밝혀야 합니다.

HTTPS 요청 하나 따라가기

일반적인 HTTPS 탐색 경로에는 여러 단계가 있습니다.

1. 경로 선택

브라우저는 고정 규칙, 프록시 자동 구성 스크립트 또는 시스템 설정을 평가합니다. 우회 규칙과 일치하면 직접 연결을 선택할 수 있습니다. 프록시 목록은 기본 프록시와 그 뒤의 대안을 선택할 수 있으며, 직접 대체 경로를 허용하면 DIRECT도 포함됩니다.

Chromium은 localhost와 링크 로컬 대상에 암묵적인 우회도 적용합니다. 이는 외부에서 통제하는 프록시 설정으로부터 로컬 오리진을 보호하지만, “모든 트래픽”이라는 넓은 설명에는 한정 조건이 필요하다는 뜻이기도 합니다.

2. 프록시 확인 및 연결

프록시 엔드포인트가 호스트 이름이라면 기기에서 여전히 그 이름을 확인하고 연결해야 합니다. 원격 대상 DNS를 사용해도 이 초기 조회는 사라지지 않습니다. 여기서의 실패는 프록시에 연결됐지만 프록시가 대상 이름을 확인하지 못한 경우와 다릅니다.

3. 프록시 인증

자격 증명이 필요한 HTTP 프록시는 일반적으로 챌린지와 함께 407 Proxy Authentication Required를 반환합니다. RFC 9110은 이 교환과 Proxy-Authenticate 및 Proxy-Authorization 필드를 정의합니다.

Chromium은 수동 프록시 설정에 포함된 사용자 이름과 비밀번호를 사용하지 않습니다. 프록시 문서는 인증이 브라우저의 일반 자격 증명 절차를 따른다고 설명합니다. 따라서 프로필 관리자에는 지원되는 챌린지를 위한 명시적인 연동이 필요하며, 임의의 user:password@host 문자열이 작동한다고 약속해서는 안 됩니다.

4. 대상 연결 설정

HTTP 프록시를 사용하면 Chromium은 대상 이름 확인을 프록시에 맡깁니다. HTTPS 대상에서는 브라우저가 프록시에 CONNECT 터널 생성을 요청한 다음 터널을 통해 대상과 종단간 TLS를 수행합니다.

프록시는 여전히 대상 호스트 이름과 연결 메타데이터를 알 수 있습니다. 클라이언트와 프록시 사이에서 평문 HTTP를 사용하면 CONNECT 요청과 호스트 이름이 해당 구간에서 보호되지 않습니다. HTTPS 프록시는 브라우저와 프록시 사이에 TLS를 추가해 그 사이의 관찰자로부터 메타데이터를 보호합니다. 프록시 자체가 요청된 대상을 볼 수 없게 하지는 않습니다.

프록시는 일반적으로 터널 안의 HTTPS 페이지 콘텐츠를 읽을 수 없습니다. TLS 가로채기는 클라이언트가 인증 기관을 신뢰해 중개자가 TLS를 종료하고 다시 생성할 수 있게 하는 다른 신뢰 모델입니다. 이를 일반 전달과 조용히 혼동해서는 안 됩니다.

프록시 스킴에 따라 달라지는 DNS 담당 주체

Chromium에 문서화된 동작은 프록시 유형마다 다릅니다.

선택한 경로	Chromium의 대상 이름 확인	중요한 한계
직접 또는 우회	기기 또는 브라우저 리졸버	대상 트래픽이 프로필 프록시 없이 나갑니다.
HTTP 프록시	프록시 측	평문 HTTP 클라이언트-프록시 전송은 HTTP 요청을 노출하고 HTTPS는 CONNECT를 사용합니다.
HTTPS 프록시	프록시 측	클라이언트가 프록시의 TLS 인증서를 검증해야 합니다.
SOCKS4 프록시	클라이언트 측	IPv4 대상만 지원하며 Chromium은 SOCKS4a 대체 경로를 구현하지 않습니다.
SOCKS5 프록시	프록시 측	Chromium은 TCP URL 요청에 사용하며 SOCKS5 인증 지원은 없다고 문서화합니다.

RFC 1928은 SOCKS5 요청에 도메인 이름을 포함할 수 있게 하고 여러 인증 방식 식별자를 정의합니다. 프로토콜이 제공하는 기능이 클라이언트 구현을 보장하지는 않습니다. Chromium은 현재 대상 이름을 SOCKS5 프록시로 보내지만 기본 SOCKS5 클라이언트가 프록시 인증 방식을 지원하지 않는다고 설명합니다. 사용자 이름과 비밀번호를 사용하는 SOCKS5를 제공하는 공급자라면 지원되는 중개자나 다른 프록시 스킴이 필요할 수 있습니다. 레코드를 받아들이기 전에 브라우저 구현을 확인하세요.

DNS-over-HTTPS는 계층을 하나 더 추가합니다. Chrome의 DnsOverHttpsMode 정책은 안전하지 않은 DNS를 대체 경로로 사용할 수 있는 automatic과 보안 DNS가 실패하면 이름 확인도 실패하는 secure를 구분합니다. 같은 문서에서 이 정책은 브라우저 수준이고 ProxySettings는 프로필 수준입니다. 이 불일치는 유용한 경고입니다. 한 설정에 “프로필”이라는 단어가 있다고 모든 DNS 통제가 같은 범위를 갖는 것은 아닙니다.

제품이 프로필마다 별도 브라우저 프로세스를 실행하면 실질적인 경계를 더 좁힐 수 있지만 이는 구현 선택입니다. 테스트하세요. 근거에서 다음을 구분해야 합니다.

• 프록시 엔드포인트 이름 확인
• 요청된 대상 이름 확인
• 직접 또는 우회 요청이 사용하는 DNS
• 보안 DNS의 초기 연결 및 대체 경로
• 프로필의 브라우저 네트워크 컨텍스트 밖의 구성 요소가 수행하는 DNS

인증은 호환성과 비밀 정보 처리의 문제입니다

Chromium은 HTTP 프록시에 Basic, Digest, Negotiate, NTLM을 문서화합니다. HTTPS 프록시는 보호된 클라이언트-프록시 채널을 추가하고 클라이언트 인증서도 지원할 수 있습니다. SOCKS5 명세에 인증 방식이 있지만 Chromium 기본 프록시 클라이언트는 SOCKS4 및 SOCKS5 인증을 구현하지 않습니다.

호환되는 스킴도 잘못된 전송에서는 안전하지 않을 수 있습니다. RFC 7617은 Basic 자격 증명이 Base64로 인코딩될 뿐이며 TLS 같은 보호된 채널이 필요하다고 설명합니다. 평문 HTTP 프록시에 Basic 인증을 사용하면 해당 구간을 관찰할 수 있는 사람에게 프록시 비밀번호가 노출됩니다.

프로필 관리자는 다음 데이터를 분리해야 합니다.

• 스킴, 호스트, 포트, 공급자 레이블 같은 비밀이 아닌 엔드포인트 메타데이터
• 수명 주기 또는 네트워크 서비스가 사용하는 비밀 정보 참조
• 보호된 저장소의 자격 증명 값
• 인터페이스 및 감사 추적을 위해 비밀 정보를 제거한 연결 상태
• 통제된 지원 절차에서만 사용할 수 있는 진단 세부 정보

일반 화면, 로그, API, 내보내기, 자동화 출력에는 프록시 비밀번호가 필요하지 않습니다. 운영자는 일반적으로 인증 실패 사실, 요청된 스킴, 관련 엔드포인트, 대체 경로 발생 여부만 알면 됩니다.

장애 유형과 증상

장애	예상 증상	확인할 경계
잘못된 프록시 스킴	TLS 또는 프로토콜 핸드셰이크 실패	HTTPS 엔드포인트를 HTTP로 선언했거나 그 반대인가요?
프록시 호스트 이름 확인 실패	프록시에 도달하기 전에 연결 실패	어떤 리졸버가 초기 조회를 수행했나요?
프록시 포트에 연결할 수 없음	시간 초과 또는 연결 거부	목록 다음에 다른 프록시나 DIRECT가 있나요?
지원하지 않는 인증 챌린지	반복되는 407 또는 로그인 프롬프트	브라우저가 요청된 스킴을 구현하나요?
자격 증명이 잘못됐거나 만료됨	자격 증명 제출 후 407	비밀 정보 참조가 해석됐고 출력에서 값이 가려졌나요?
HTTPS 프록시 인증서 실패	프록시와의 보안 연결 거부	인증서 검증이 유지되고 있나요?
프록시가 대상 이름을 확인하지 못함	프록시별 호스트 또는 터널 실패	클라이언트가 대상에 직접 재시도하지 않았나요?
CONNECT 거부	해당 대상의 HTTPS 탐색 실패	거부를 우회 권한이 아니라 정책으로 처리하나요?
PAC 파일 사용 불가	프록시 결정 지연 또는 경로 변경	PAC가 필수인가요, 아니면 Chromium이 조용히 DIRECT를 사용할 수 있나요?
우회 패턴이 너무 넓음	선택된 사이트가 직접 연결	정확한 호스트, 하위 도메인, 포트, 암묵적 규칙을 이해하고 있나요?
WebRTC가 다른 인터페이스 사용	미디어 경로가 페이지 트래픽과 다름	프로필에서 비프록시 UDP가 비활성화됐나요?
설정 변경 후 기존 연결 유지	이전 경로가 잠시 활성 상태로 남음	연결을 종료하거나 프로필을 다시 시작하나요?
지나치게 상세한 진단 캡처	URL, 호스트 이름 또는 비밀 정보가 지원 파일에 들어감	어떤 비밀 정보 제거 모드와 보존 규칙이 적용되나요?

Chromium의 대체 경로는 상태를 가집니다. 연결 수준 장애가 난 프록시는 일정 시간 비정상으로 표시되어 다른 항목 뒤로 이동할 수 있습니다. 목록에 DIRECT가 있으면 이후 요청이 프록시 없이 나갈 수 있습니다. CONNECT 거부는 의도된 대상 정책일 수 있으므로 사용할 수 없는 프록시와 다르게 처리됩니다.

PAC 장애에는 특히 주의해야 합니다. Chromium은 사용할 수 없는 PAC 파일이 필수로 표시되지 않으면 조용히 직접 연결 결정을 사용할 수 있다고 문서화합니다. Chrome의 ProxySettings 정책은 이러한 직접 대체 경로를 막기 위해 ProxyPacMandatory를 제공합니다.

WebRTC와 UDP는 별도로 결정하기

페이지는 일반 HTTP 및 HTTPS URL 요청과 다른 WebRTC 경로를 사용할 수 있습니다. Chrome의 기본 WebRtcIPHandling 정책은 사용 가능한 모든 인터페이스를 사용할 수 있습니다. disable_non_proxied_udp 모드는 구성된 프록시가 UDP를 지원하지 않는 한 공개 인터페이스에서 WebRTC를 TCP로 제한합니다.

이 정책은 프로필 수준으로 문서화되어 프로필 프록시와 관련 있지만 별도 통제로 남습니다. 미디어 성능을 떨어뜨리거나 직접 UDP가 필요한 업무를 중단시킬 수 있습니다. 절충을 명시적으로 선택하고 테스트하세요. 페이지 로드 검사 하나가 성공했다는 이유로 완전한 프록시 억제를 주장하지 마세요.

장애 시 차단과 가용성 사이에서 결정하기

가용성을 중시하는 일반 브라우징 프로필에서는 직접 대체 경로가 합리적일 수 있습니다. 권한, 개인정보 보호 또는 지역 테스트의 유효성이 특정 출구 경로에 의존하는 업무에는 안전하지 않습니다.

좋은 프로필 정책은 의도한 동작을 명시합니다.

• 필수 프록시: 선택한 경로를 사용할 수 없으면 관련 네트워크 요청을 중단합니다.
• 승인된 프록시 집합: 동등한 정책을 가진 명시된 대안만 시도합니다.
• 직접 대체 경로 허용: 경로 변경을 표시하고 비밀 값 없이 이벤트를 기록합니다.
• 명시적 우회: 대상 유형과 직접 접근이 필요한 이유를 문서화합니다.

인터페이스는 실행 전과 장애 후에 경로 상태를 보여 줘야 합니다. 프록시에서 직접 연결로 조용히 바뀌면 네트워크 오류가 무결성 오류로 변합니다. 업무가 잘못된 경로를 사용하면서도 성공한 것처럼 보일 수 있습니다.

안전한 검증 매트릭스

직접 소유하거나 검사 권한이 있는 엔드포인트와 DNS 영역에서 테스트하세요. 테스트 전에 예상 결과를 기록하세요.

1. 선언된 프록시 스킴을 실제 엔드포인트 전송과 대조합니다.
2. HTTP, HTTPS, WebSocket, 필요한 WebRTC 동작이 성공하는지 확인합니다.
3. 통제된 대상에서 출구 주소를 관찰합니다.
4. 어떤 리졸버가 대상 조회를 받고 어떤 리졸버가 프록시 호스트 이름을 처음 확인하는지 관찰합니다.
5. 테스트 자격 증명을 만료시키고 원본 값이 인터페이스, 로그 또는 자동화 출력에 나타나지 않는지 확인합니다.
6. 테스트 프록시에 연결할 수 없게 만들고 구성된 실패 시 차단 또는 대체 경로 결과를 확인합니다.
7. 통제된 CONNECT 대상 하나를 거부하고 정책 거부가 직접 접근으로 바뀌지 않는지 확인합니다.
8. 테스트 PAC를 사용할 수 없게 만들고 필수 동작을 확인합니다.
9. 업무에 필요한 정확한 호스트, 하위 도메인, 로컬, 링크 로컬, IPv4, IPv6 우회 사례를 실행합니다.
10. 연결이 활성 상태일 때 프록시를 변경하고 새 경로가 적용되는 시점을 확인합니다.
11. 테스트에 필요한 진단 세부 정보만 캡처한 다음 보존 및 삭제를 확인합니다.

Chromium의 NetLog 지침은 네트워크 로깅을 개인정보 보호 및 보안 문제로 다룹니다. 비밀 정보를 제거한 모드는 민감한 필드를 생략할 수 있지만 더 자세한 모드에는 쿠키나 인증 헤더가 들어갈 수 있습니다. 지원 파일은 파일 이름이 아니라 실제 캡처 모드에 따라 처리해야 합니다.