Chrome만 Clash? PAC·시스템 프록시 분리 (2026)

왜 시스템 프록시와 분리할까

시스템 프록시는 WinHTTP·많은 데스크톱 앱·일부 스토어 앱이 따라오도록 설계되어 있습니다. 업무용 PC에서는 사내 ISA·Explicit 프록시가 이미 잡혀 있거나, WPAD로 자동 설정되는 경우가 많습니다. 여기에 Clash가 같은 레이어에서 HTTP 프록시 서버 필드를 덮어쓰면, 패키지 매니저·VPN 클라이언트·게임 런처가 의도와 다른 출구를 타거나, 아예 실패하는 일이 생깁니다. 그래서 “브라우저만 분기하겠다”는 요구는 실무에서 자주 나옵니다.

한편 Chrome만 목표로 할 때도 TUN 모드로 전체 트래픽을 가로채는 방식과는 목적이 다릅니다. 터미널의 git·npm까지 같은 노드를 쓰려면 WSL2와 호스트 프록시 같은 다른 글이 맞고, 본문은 브라우저 PAC라는 얇은 레이어만 다룹니다. 규칙·DNS 자체는 문서 허브와 동일하게 유지합니다.

1먼저 확인: Clash의 로컬 포트

PAC는 결국 “이 URL은 어떤 프록시 호스트:포트로 보낼지”를 적어 주는 스크립트입니다. 그 전에 Clash Verge Rev·Mihomo 등에서 mixed-port(예: 7890)·또는 나뉜 HTTP·SOCKS 포트가 무엇인지 확인하세요. 브라우저 PAC에서 가장 흔한 형태는 PROXY 127.0.0.1:포트 또는 SOCKS가 필요하면 SOCKS5 127.0.0.1:포트입니다. mixed-port 하나로 HTTP를 받는 구성이면 PROXY 한 줄로 충분한 경우가 많습니다.

참고: 포트 번호는 프로필마다 다릅니다. 스크린샷의 예시(7890 등)를 그대로 복사하지 말고, 본인 앱의 포트 표시를 기준으로 PAC를 고치세요.

PAC 스크립트 최소 예시

아래는 설명용입니다. 실제로는 사내망·사설 대역을 DIRECT로 두고, 나머지만 프록시하는 식으로 회사 정책에 맞게 조정해야 합니다. FindProxyForURL은 호스트·경로마다 다른 문자열을 돌려 줍니다.

function FindProxyForURL(url, host) {
  // Example — replace 7890 with your Clash mixed-port / HTTP port
  if (isPlainHostName(host) ||
      shExpMatch(host, "*.local") ||
      isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
      isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0") ||
      isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0")) {
    return "DIRECT";
  }
  return "PROXY 127.0.0.1:7890";
}

dnsResolve는 PAC 실행 환경에 따라 실패하거나 지연될 수 있어, 엄격한 사내 환경에서는 IT 가이드 없이 도메인 패턴만으로 나누는 편이 안전할 때도 있습니다. 반대로 테스트 단계에서는 위처럼 대역을 빼 두면 “내부 사이트만 직결”을 빠르게 확인할 수 있습니다.

2Windows: Chrome에만 PAC 넣기

파일 PAC과 로컬 URL

프록시 PAC 파일을 예를 들어 C:\proxy\chrome-clash.pac에 저장했다면, Chrome 실행 인수에 --proxy-pac-url=file:///C:/proxy/chrome-clash.pac 형태로 넘깁니다(슬래시 방향·드라이브 문자 주의). 또는 간단한 로컬 HTTP 서버로 같은 파일을 호스팅해 http://127.0.0.1:8080/chrome-clash.pac처럼 줄 수도 있습니다. 바탕화면 바로가기의 “대상” 필드를 고치면 매번 명령줄을 치지 않아도 됩니다.

시스템 프록시 메뉴와의 관계

Windows 설정의 “프록시 사용”를 끄면, OS 전역으로는 직결이 유지되고 Chrome 전용 인수로만 PAC가 적용되는 그림을 만들 수 있습니다. 다만 다른 브라우저·Electron 앱은 기본적으로 이 PAC를 모릅니다. Microsoft Store 앱·루프백 이슈는 UWP Loopback 글과 결이 비슷하지만, 여기서는 OS 설정을 건드리지 않는 방향을 우선합니다.

3macOS: 시스템 네트워크와 분리한 Chrome

macOS에서는 시스템 설정 > 네트워크의 자동 프록시 구성과 별개로, 터미널이나 open 명령으로 --proxy-pac-url=...를 준 Chrome 프로세스만 다른 PAC를 쓰게 할 수 있습니다. 조직 단말에서는 MDM이 프록시 프로파일을 고정하는 경우가 있으므로, 변경 전 정책을 확인하세요.

키체인·Helper 이슈로 시스템 프록시가 안 먹는 증상은 macOS 시스템 프록시 튜토리얼에 정리되어 있습니다. 브라우저 단독 PAC를 쓰면 그 레이어를 우회하는 대신, 여전히 Clash 코어가 리스닝 중이어야 하며, 방화벽이 로컬 포트를 막지 않는지 확인해야 합니다.

자동 감지 프록시(WPAD)·회사 PAC와 겹칠 때

사무실망에서 이미 WPAD나 원격 PAC URL이 배포되어 있다면, Chrome 단독 PAC와 충돌하거나 우선순위가 헷갈릴 수 있습니다. 이때는 “브라우저 실행 인수로 우리 PAC만 쓴다”는 전제가 깨지지 않게, IT 안내에 따라 직접 연결 프로파일을 쓰는지·프록시 체인을 쓰는지부터 정리해야 합니다. 본 글은 법인 환경에서의 예외를 모두 커버하지 못하므로, 필요하면 내부 네트워크 담당 정책을 우선합니다.

4검증 순서

Clash 대시보드에서 코어가 실행 중이고, 테스트할 노드가 살아 있는지 확인합니다.
PAC에 적어 둔 127.0.0.1:포트가 구성과 일치하는지 다시 봅니다.
Chrome으로만 확장 프로그램이 없는 시크릿 창을 열어 IP·DNS 확인 사이트를 보고, 동일 기기의 다른 브라우저와 결과가 의도대로 다른지 비교합니다.
문제가 지속되면 시스템 프록시를 켠 적이 있는지, 다른 보안 제품이 로컬 프록시를 필터링하지 않는지 점검합니다.

준수: 소속 기관의 네트워크·보안 정책과 서비스 약관을 지키세요. 사내 장비에서는 프록시·PAC 변경 전 담당 부서 승인을 받으십시오.

TUN·전역 프록시와의 선택

특정 앱만 프록시해야 한다면 PROCESS-NAME 규칙이나 TUN 모드가 필요할 수 있습니다. 반대로 “브라우저만”이면 PAC·실행 인수만으로도 충분한 경우가 많아, 전역 부작용을 줄이는 데 유리합니다. 두 방식을 혼용할 때는 어떤 프로세스가 어떤 레이어를 타는지 한 번에 바꾸지 말고, 변수 하나씩 줄여 보세요.

마치며

Chrome만 Clash로 보내려면, 핵심은 OS의 시스템 프록시 대신 PAC와 브라우저 실행 옵션으로 출구를 좁히는 것입니다. Windows·macOS 모두 로컬 HTTP·SOCKS 포트만 맞으면 같은 아이디어를 재사용할 수 있고, 나머지 앱은 기존처럼 직결이나 회사 프록시를 유지할 수 있습니다. 클라이언트 패키지는 릴리스 직링크보다 사이트의 다운로드 허브를 기준으로 받는 편이 플랫폼별 혼선이 적습니다.

다른 도구와 비교해 보아도, 규칙 편집·로그 가독성·프로필 관리 측면에서 Clash 계열 클라이언트는 장기 사용에 익숙해지기 쉬운 편입니다. 오픈소스 본문·이슈 트래킹은 GitHub로 확인하고, 설치 파일은 아래 링크를 우선해 보세요.

→ Clash를 무료로 다운로드하고, 브라우저 전용 PAC와 시스템 설정을 원하는 대로 나누어 보세요

Chrome만 Clash를 타게 하기: PAC와 시스템 프록시 분리 설정 (Windows / macOS, 2026)