Clash 시스템 프록시 미작동 해결: 브라우저와 터미널 명령줄을 나눠서 진단하기

B-01먼저 문제가 어느 단계에서 발생하는지 구분하기

“Clash를 켰는데 작동하지 않는다”는 매우 모호한 표현입니다. 실제 원인을 파악하려면 먼저 “시스템 프록시 적용 범위”라는 큰 그림을 이해해야 합니다. Clash 클라이언트가 시스템 프록시 모드에서 하는 일은 운영체제의 네트워크 설정을 수정하는 것입니다(Windows의 인터넷 옵션 레지스트리 항목, macOS의 네트워크 서비스 프록시 필드). 이렇게 하면 시스템 프록시 스택을 따르는 프로그램이 로컬 리스닝 포트(보통 HTTP 프록시 127.0.0.1:7890 또는 혼합 포트)를 자동으로 사용하게 됩니다. 하지만 운영체제의 “시스템 프록시” 스위치는 시스템 프록시 설정을 따르는 프로그램에만 적용되며, 브라우저·터미널 명령줄·일부 백그라운드 서비스는 이를 따르는 정도가 각기 다릅니다.

따라서 같은 “작동하지 않음” 증상이라도 브라우저 쪽과 터미널 쪽의 진단 방향은 완전히 다릅니다. 이를 뭉쳐서 처리하면 오히려 더 헷갈리게 됩니다. 이 글은 “브라우저 단계—시스템 단계—터미널 단계” 세 부분으로 나누어 점검 목록을 제시하고, 마지막에 검증 명령어를 소개합니다. 순서대로 하나씩 확인하시길 권장합니다.

B-02브라우저 단계 점검: 확장 프로그램 충돌과 내장 프록시 설정 우선순위

브라우저가 프록시를 타지 않는 것은 가장 흔한 문의 사항으로, 원인은 주로 세 가지에 집중되어 있습니다. 우선순위대로 하나씩 점검하세요.

1. 프록시 관리 확장 프로그램이 설치되어 있는 경우

SwitchyOmega, Proxy SwitchySharp 같은 확장 프로그램은 브라우저의 프록시 설정 인터페이스를 가로챕니다. 설치 후 활성화되면 브라우저는 운영체제의 시스템 프록시보다 확장 프로그램의 설정을 우선 따릅니다. 이런 확장 프로그램이 현재 “직접 연결” 상태거나 이미 사용할 수 없는 다른 포트를 가리키고 있다면, Clash가 시스템 프록시를 제대로 설정했더라도 브라우저는 여전히 연결되지 않습니다. 해결 방법은 확장 프로그램에 Clash의 로컬 포트를 가리키는 규칙을 새로 만들거나, 확장 프로그램을 임시로 비활성화하고 정상화되는지 확인하는 것입니다.

2. 브라우저 기업 정책 또는 이전 설정 잔여물

일부 브라우저(특히 기업 환경에 미리 설치된 버전)는 그룹 정책으로 프록시 설정이 강제 고정되어 있어 시스템 프록시 변경이 반영되지 않습니다. 브라우저 주소창에서 내장 네트워크 설정 페이지에 접속해 프록시 출처가 “시스템 프록시 설정 사용”으로 표시되는지, “직접 연결”이나 “수동 설정”이 아닌지 확인하세요. 수동 설정 상태로 이전 주소를 가리키고 있다면 초기화 후 브라우저를 재시작하면 됩니다.

3. PAC 스크립트 모드에서 포트나 규칙이 잘못된 경우

일부 버전의 Clash 클라이언트는 PAC(Proxy Auto-Config) 스크립트 방식으로 시스템 프록시를 관리하는 기능을 지원합니다. PAC 스크립트의 판단 로직에 오류가 있거나 리스닝 포트가 클라이언트 실제 사용 포트와 일치하지 않으면, 브라우저가 PAC 스크립트를 실행한 결과가 “직접 연결”로 나와 완전히 프록시를 타지 않는 것처럼 보입니다. 먼저 표준 “시스템 프록시” 모드(PAC 미사용)로 전환해 문제가 사라지는지 확인한 뒤, PAC를 계속 사용할지 결정하는 것을 권장합니다.

B-03시스템 단계 점검: 시스템 프록시가 실제로 기록되었는지 확인

브라우저 쪽을 점검해도 해결되지 않았다면, 한 단계 물러나 “시스템 프록시” 계층 자체가 실제로 적용되었는지 확인해야 합니다. Clash 스위치가 켜져 있다고 해서 반드시 반영되었다고 단정하면 안 됩니다.

Windows: 인터넷 옵션 확인

“제어판 → 네트워크 및 인터넷 → 인터넷 옵션 → 연결 → LAN 설정”을 열어 “LAN에 프록시 서버 사용”이 체크되어 있는지, 주소와 포트가 Clash 클라이언트 설정 화면에 표시된 값과 일치하는지 확인하세요. 이 항목이 비어 있다면 클라이언트의 “시스템 프록시로 설정” 스위치가 실제로 기록되지 않은 것입니다. 흔한 원인은 클라이언트 권한 부족(관리자 권한으로 실행 필요)이거나, 다른 프록시 소프트웨어(예: 기업 VPN 클라이언트)와 기록 충돌이 발생해 나중에 실행된 쪽이 앞선 설정을 덮어쓴 경우입니다.

macOS: 네트워크 서비스의 프록시 필드 확인

“시스템 설정 → 네트워크 → 현재 사용 중인 네트워크 서비스 → 세부 정보 → 프록시”에서 “웹 프록시(HTTP)”와 “보안 웹 프록시(HTTPS)”가 체크되어 있고 Clash의 리스닝 주소와 포트가 입력되어 있는지 확인하세요. macOS에서 여러 네트워크 서비스가 동시에 활성 상태인 경우(예: 이더넷과 Wi-Fi가 모두 연결된 상태) Clash는 현재 우선순위가 높은 서비스에만 값을 기록하는데, 실제 라우팅은 다른 서비스를 통해 이루어지고 있다면 “설정했는데 작동하지 않는” 착시가 발생합니다. 실제로 적용되는 네트워크 서비스와 Clash가 값을 기록한 서비스가 같은지 확인해야 합니다.

B-04터미널 명령줄이 프록시를 타지 않는 이유: 핵심은 환경 변수

터미널(Terminal, PowerShell, Bash)에서 사용하는 curl, wget, git, npm, pip 등의 명령줄 도구는 대부분 시스템 프록시 설정을 읽지 않고, 각자 정해진 환경 변수를 참조합니다. 이것이 터미널이 프록시를 타지 않을 때 가장 자주 놓치는 근본 원인입니다. 시스템 프록시가 제대로 기록되고 브라우저도 정상적으로 인터넷에 접속되는데 터미널에서만 타임아웃이나 연결 실패가 뜬다면, 이는 고장이 아니라 별도의 설정 단계가 필요한 정상적인 현상입니다.

수동으로 설정해야 하는 환경 변수

대부분의 명령줄 도구는 http_proxy, https_proxy(대문자 형태인 HTTP_PROXY, HTTPS_PROXY 포함) 이 두 환경 변수를 따르며, 값에는 Clash 클라이언트의 로컬 HTTP 프록시 리스닝 주소를 입력합니다.

macOS / Linux(Bash 또는 Zsh), 임시 적용, 현재 터미널 세션에만 유효:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

터미널을 열 때마다 자동으로 적용되게 하려면 위 두 줄을 ~/.zshrc 또는 ~/.bash_profile 파일 끝에 추가하고 저장한 뒤 source ~/.zshrc를 실행해 바로 적용하세요.

Windows PowerShell, 임시 적용:

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

영구적으로 적용하려면 PowerShell 프로필($PROFILE이 가리키는 스크립트)에 같은 두 줄을 추가하거나, 시스템 환경 변수 설정 화면에서 사용자 수준 변수를 새로 만들면 됩니다.

일부 도구는 별도의 프록시 설정을 사용함

git은 위의 환경 변수를 설정해도 일부 버전에서는 HTTPS 프로토콜 저장소에 적용되도록 별도 설정이 필요합니다:

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

npm과 pip도 마찬가지로, 각각 npm config set proxy / npm config set https-proxy를 사용하거나 pip install 실행 시 --proxy 옵션을 추가하거나 pip.conf에 설정합니다. 이런 도구들의 개별 설정 항목은 환경 변수보다 우선순위가 높습니다. 환경 변수를 설정했는데도 여전히 프록시를 타지 않는다면, 해당 도구에 별도의 프록시 설정 항목이 있어 덮어쓰고 있지 않은지 먼저 확인하세요.

B-05TUN 모드로 시스템 프록시와 환경 변수의 이중 설정 우회하기

특정 프로그램이 시스템 프록시도 따르지 않고 환경 변수도 읽지 않는 상황(일부 GUI 애플리케이션, 게임 클라이언트, 일부 언어 런타임의 네트워크 라이브러리에서 흔함)을 자주 겪는다면, TUN 모드로 전환하는 편이 훨씬 간단합니다. TUN 모드는 Clash Meta(mihomo 코어) 및 이를 기반으로 한 클라이언트(Clash Verge Rev, FlClash 등)에서 지원하며, 가상 네트워크 카드를 만들어 시스템의 모든 아웃바운드 트래픽을 가로채는 방식입니다. 애플리케이션 계층이 프록시 설정을 읽는지 여부와 무관하게 작동하므로 브라우저와 터미널 명령줄이 동시에 적용되며 각각 따로 설정할 필요가 없습니다.

TUN 모드를 켜려면 보통 클라이언트가 가상 네트워크 카드를 만들기 위해 관리자/Root 권한을 요구합니다. macOS와 일부 Linux 배포판은 네트워크 확장 구성 요소를 추가로 설치해야 할 수 있습니다. 구체적인 활성화 방법은 각 클라이언트의 “TUN 모드” 또는 “Tun 네트워크 카드” 설정 항목에서 확인할 수 있으며, 활성화 전에 시스템 프록시 옵션을 먼저 꺼서 두 가지 가로채기 방식이 중첩되어 라우팅 이상이 발생하지 않도록 하는 것을 권장합니다.

B-06하나씩 검증하기: 수정 사항이 실제로 적용되었는지 확인

설정을 변경한 뒤 “느낌상 인터넷이 되는 것 같다”로 결론을 내리지 말고, 아래 명령어들로 하나씩 검증해 시스템 프록시가 적용된 것인지, 터미널이 적용된 것인지, 아니면 여전히 적용되지 않은 것인지 명확히 구분하세요.

터미널 환경 변수가 읽혀서 실제로 프록시를 타고 있는지 검증:

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

HTTP/1.1 204 No Content가 반환되면 프록시 포트 자체는 정상 작동한다는 뜻입니다. 이어서 -x 옵션 없이, 이미 설정한 환경 변수에만 의존해 다시 한번 테스트합니다:

curl https://www.gstatic.com/generate_204 -I

이번에도 204가 반환되면 환경 변수가 curl에 실제로 읽혀서 적용되고 있다는 뜻입니다. 타임아웃이 발생하거나 바로 실패한다면 환경 변수가 현재 세션에 제대로 내보내지지 않은 것이므로, 변수명 대소문자와 설정 파일이 제대로 로드되었는지 다시 확인하세요.

시스템 프록시 포트가 시스템에 올바르게 등록되었는지 검증(Windows PowerShell):

netsh winhttp show proxy

이 명령어가 표시하는 것은 WinHTTP 계층의 프록시 설정으로, 브라우저가 사용하는 WinINet 계층 설정과 완전히 일치하지 않을 수 있습니다. 두 곳에 표시되는 주소가 다르다면 이것도 브라우저가 프록시를 타지 않는 흔한 원인 중 하나이므로, 브라우저의 프록시 설정에서 직접 확인해야 합니다.

• 브라우저가 프록시를 타지 않을 때: 확장 프로그램 → 내장 프록시 출처 → PAC 스크립트 오류 순서로 확인하세요.
• 시스템 프록시 스위치가 켜져 있어도 작동하지 않을 때: Windows 인터넷 옵션 / macOS 네트워크 서비스 프록시 필드에 실제로 기록되었는지, 여러 네트워크 서비스 간 충돌이 있는지 확인하세요.
• 터미널 명령줄이 프록시를 타지 않을 때: http_proxy / https_proxy 환경 변수를 설정하고, git, npm, pip 등 도구는 각각 별도 설정 항목을 확인하세요.
• 같은 문제가 반복해서 발생할 때: TUN 모드로 전환해 전역 트래픽을 한 번에 관리하는 것을 고려하세요.