Clash 시스템 프록시가 작동하지 않을 때: 브라우저와 터미널별 점검 방법

시스템 프록시, 앱 프록시, TUN의 차이부터 확인

Clash 클라이언트의 ‘시스템 프록시’ 스위치는 보통 로컬 프록시 주소를 운영체제의 프록시 설정에 등록하는 기능입니다. 모든 네트워크 연결을 강제로 가로채는 것은 아닙니다. 브라우저, 명령줄 도구, 백그라운드 서비스가 서로 다른 설정을 참조할 수 있으므로 ‘웹페이지는 열리는데 터미널 연결은 시간 초과’되는 상황도 충분히 발생할 수 있습니다.

문제 해결을 시작할 때는 두 가지를 확인하세요. 요청이 Clash 코어에 도달했는지, 도달했다면 어떤 규칙이 적용됐는지입니다. 첫 번째는 프록시 진입 경로 문제이고, 두 번째는 구독 노드, 정책 그룹, 라우팅 설정과 관련된 문제입니다. 출구 IP가 바뀌지 않았다는 이유만으로 시스템 프록시가 작동하지 않는다고 단정하지 마세요.

1단계: 로컬 프록시가 작동하는지 확인

외부 제어 포트가 아닌 혼합 포트 확인

클라이언트의 설정 또는 구성 화면에서 mixed-port를 찾으세요. 혼합 포트는 HTTP와 SOCKS 프록시 요청을 모두 받습니다. external-controller는 관리 API가 수신 대기하는 주소이므로 웹 프록시로 사용할 수 없습니다. 흔히 예시로 나오는 9090은 제어 포트일 뿐입니다. 포트가 열려 있다는 이유로 브라우저 프록시 주소에 입력하지 마세요.

mixed-port: 7890
external-controller: 127.0.0.1:9090

먼저 커널이 실행 중이고 구독 설정이 선택되어 있는지 확인한 다음, 프록시를 명시한 명령으로 테스트하세요. Windows PowerShell에서는 curl.exe를 사용하세요. 구형 Windows PowerShell은 curl을 다른 명령으로 해석할 수 있습니다.

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

--noproxy ""는 이번 요청에서 프록시 우회 목록을 비워 기존 NO_PROXY 설정의 영향을 막습니다. 여기서 10초는 연결 제한 시간, 20초는 전체 요청 제한 시간입니다. 노드 지연 시간을 나타내는 기준값은 아닙니다. 테스트 주소는 문제가 발생한 사이트로 바꿔도 되지만, 로그인 토큰이 포함된 전체 URL은 공개 로그에 남기지 마세요.

• 127.0.0.1:7890에 연결할 때 연결이 거부된다면 커널이 실행 중인지, 포트를 잘못 입력하지 않았는지, 다른 프로세스가 해당 포트를 사용 중인지 먼저 확인하세요.
• HTTP 프록시 터널에서 200 Connection established가 표시되면 로컬 프록시가 CONNECT 요청을 수락한 것입니다. 이후 TLS 및 HTTP 결과도 계속 확인해야 합니다.
• 로컬 연결은 성공했지만 이후 시간 초과가 발생하거나 TLS 오류가 나타난다면 노드 연결, 대상 사이트, DNS 또는 인증서를 확인하세요. 시스템 프록시 스위치만 계속 살펴볼 단계는 아닙니다.

클라이언트의 ‘연결’ 또는 ‘로그’ 화면을 함께 열고 새 요청을 보내세요. 로그 수준은 잠시 info로 설정하고, 꼭 필요한 경우에만 debug를 사용한 다음 원래대로 되돌리세요. 프록시를 명시한 명령은 성공하지만 브라우저에서 실패한다면 대개 브라우저 자체의 진입 설정에 문제가 있습니다.

2단계: 시스템 프록시가 실제로 설정된 위치 확인

Windows 11: 수동 프록시와 설정 스크립트 확인

‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 ‘수동 프록시 설정’ 아래의 ‘프록시 서버 사용’을 확인하세요. 이 글의 예시를 사용하는 경우 주소는 127.0.0.1, 포트는 7890이어야 합니다. 클라이언트에서 시스템 프록시를 켠 뒤 이 화면으로 돌아와 값이 실제로 바뀌었는지 확인하세요. 클라이언트 버튼의 색상만 보고 판단하지 마세요.

‘설정 스크립트 사용’이 켜져 있는지, 프록시 예외 목록에 대상 도메인이 포함되어 있는지도 확인하세요. 자동 구성 스크립트, 조직 정책 또는 다른 네트워크 도구가 실제 동작에 영향을 줄 수 있습니다. 관리되는 기기라면 관리자에게 먼저 문의하고, 조직에서 배포한 설정을 임의로 삭제하지 마세요.

netsh winhttp show proxy는 WinHTTP 프록시 설정을 보여줄 뿐, 이 설정 화면의 전체 상태를 나타내지는 않습니다. 일부 서비스는 WinHTTP를 사용하지만 브라우저는 시스템 프록시 해석 방식이나 자체 설정을 사용할 수 있습니다. 출력 결과를 일치시키려고 전역 가져오기 명령을 바로 실행하지 마세요. 문제가 있는 프로그램이 실제로 어떤 네트워크 인터페이스를 사용하는지 먼저 확인하세요.

macOS: 현재 연결된 네트워크 서비스 확인

macOS 13 이상에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 사용하는 Wi-Fi 또는 이더넷 → ‘세부사항’ → ‘프록시’로 이동하세요. 웹 프록시(HTTP), 보안 웹 프록시(HTTPS), 자동 프록시 구성을 확인합니다. Wi-Fi에서 유선 네트워크로 전환했다면 이전 Wi-Fi 설정이 아니라 새 연결에 해당하는 서비스를 확인해야 합니다.

HTTPS 웹페이지에 HTTP 프록시를 사용할 때는 일반적으로 CONNECT로 터널을 설정합니다. 로컬 프록시 주소를 http://127.0.0.1:7890으로 입력해도 웹페이지의 HTTPS 암호화가 해제되는 것은 아니며, 로컬 주소를 https://로 바꿀 필요도 없습니다. 프록시 서버 자체가 TLS를 지원하는지는 별개의 문제입니다.

Linux: 데스크톱 설정이 모든 프로그램에 적용되는 것은 아닙니다

GNOME 데스크톱에서는 ‘설정’ → ‘네트워크’ → ‘네트워크 프록시’에서 수동 또는 자동 모드를 확인할 수 있습니다. 다른 데스크톱 환경에서는 메뉴 이름이 다를 수 있습니다. 데스크톱 프록시는 해당 설정을 읽는 앱에만 적용되는 경우가 많으며, 모든 셸, 컨테이너, systemd 서비스에 환경 변수를 자동으로 설정해 주지는 않습니다. Linux 터미널에서 연결되지 않는다면 다음 절에서 환경 변수와 프로그램 설정도 확인하세요.

3단계: 브라우저 확장 프로그램, 예외 설정, 기존 연결 확인

같은 브라우저에서 새 창을 열어 동일한 테스트 주소에 접속하고, Clash 연결 화면에서 새 요청을 확인하세요. 기존 HTTP/2 또는 HTTP/3 연결이 계속 재사용될 수 있습니다. 스위치를 바꾼 뒤 페이지를 새로고침하는 것만으로는 새 연결 경로가 제대로 반영되지 않을 수 있으므로, 필요하면 브라우저를 완전히 종료한 뒤 다시 실행하세요.

1. Chrome 및 Edge: 브라우저 ‘설정’에서 ‘프록시’를 검색한 다음 컴퓨터의 프록시 설정을 여세요. 데스크톱 버전은 일반적으로 시스템 프록시를 사용하지만, 프록시 확장 프로그램, 실행 옵션, 기업 정책이 설정을 덮어쓸 수 있습니다.
2. 프록시 확장 프로그램 확인: 프록시를 관리하는 확장 프로그램을 잠시 사용 중지하거나 ‘시스템 프록시’ 모드로 전환하세요. 확장 프로그램의 고정 프록시, PAC 스크립트, 클라이언트의 시스템 프록시가 서로 설정을 덮어쓰지 않도록 하세요.
3. Firefox: ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 여세요. ‘시스템 프록시 설정 사용’을 선택하거나 수동 프록시로 따로 테스트해 ‘프록시 사용 안 함’을 잘못 선택하지 않았는지 확인하세요.
4. 우회 목록 확인: 브라우저와 시스템의 ‘프록시 사용 안 함’ 또는 예외 항목을 살펴보세요. 대상 도메인이 여기에 포함되면 프록시를 거치지 않고 직접 연결될 수 있습니다.

Firefox에서 수동으로 설정할 때는 HTTP 프록시에 127.0.0.1과 실제 혼합 포트를 입력하고, 화면의 옵션에 따라 HTTPS에도 같은 HTTP 프록시를 사용하도록 설정할 수 있습니다. SOCKS v5를 사용한다면 ‘SOCKS v5 사용 시 DNS 프록시’ 옵션을 확인하세요. HTTP 프록시와 SOCKS의 DNS 처리 방식을 혼동하지 마세요.

요청이 Clash에 도달했지만 DIRECT가 적용된다면 규칙 모드, 일치한 규칙, 정책 그룹 선택을 확인하세요. 시스템 프록시가 요청을 전달해도 모든 웹사이트가 원격 노드를 통해 나가는 것은 아닙니다. 출구 IP를 한 번 확인한 결과는 해당 검사 요청의 경로만 보여줄 뿐, 브라우저의 모든 연결을 나타내지는 않습니다.

4단계: 터미널 환경 변수와 도구별 프록시 설정 확인

시스템 프록시를 켜도 터미널이 자동으로 프록시를 사용하지 않는 경우가 많습니다. 앞서 소개한 프록시 명시 명령을 먼저 실행하세요. 이 명령은 성공하지만 일반 curl 요청은 실패한다면 현재 셸의 환경 변수를 우선 확인하세요. 변수 이름의 대소문자 지원은 도구마다 다릅니다. 예를 들어 curl은 보안상의 이유로 HTTP 프록시 변수에 대문자 HTTP_PROXY를 허용하지 않습니다.

PowerShell: 현재 세션에서만 설정

# 기존 프록시 변수 확인
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

# 현재 PowerShell과 이후 실행되는 자식 프로세스에 프록시 설정
$env:http_proxy = 'http://127.0.0.1:7890'
$env:https_proxy = 'http://127.0.0.1:7890'

# 새 요청으로 확인
curl.exe -v --connect-timeout 10 --max-time 20 https://example.com/ -o NUL

이 값을 설정해도 현재 PowerShell 프로세스와 그 이후에 실행되는 자식 프로세스에만 적용됩니다. 이미 열려 있는 IDE, 다른 터미널, 시스템 서비스에는 적용되지 않습니다. Windows에서는 환경 변수 이름의 대소문자를 일반적으로 구분하지 않지만, macOS와 Linux에서는 대소문자 차이에 유의해야 합니다.

macOS / Linux: 현재 셸 확인

# 프록시 관련 변수 확인
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

# 현재 셸에 HTTP 프록시 설정
export http_proxy='http://127.0.0.1:7890'
export https_proxy='http://127.0.0.1:7890'

# 새 요청 실행
curl -v --connect-timeout 10 --max-time 20 https://example.com/ -o /dev/null

https_proxy 값에 http://를 사용하는 것은 정상입니다. HTTP 프록시를 통해 HTTPS 대상에 접속한다는 뜻입니다. NO_PROXY 또는 no_proxy에 대상 도메인이 포함되어 있으면 요청이 프록시를 우회할 수 있습니다. 값을 *로 설정하면 해당 도구의 모든 요청이 직접 연결될 수도 있습니다. 실제로 필요한 로컬 주소 예외는 유지하고, 이번 문제와 관련된 항목만 조정하세요.

환경 변수가 올바른데도 프로그램이 프록시를 사용하지 않을 때

모든 명령줄 프로그램이 이 환경 변수를 지원하는 것은 아닙니다. 예를 들어 Git은 전용 설정과 설정 출처를 확인할 수 있습니다.

git config --show-origin --get-regexp '.*proxy.*'

출력에 이전 포트나 다른 컴퓨터의 프록시가 표시되면 설정이 저장된 파일과 적용 범위를 먼저 기록한 뒤 해당 항목을 수정하세요. 프로젝트 설정, 전역 설정, URL별 설정이 동시에 적용될 수 있으므로 한 곳만 바꾸고 해결되지 않는다고 판단하지 마세요. IDE 내장 터미널은 IDE를 시작할 때의 환경 변수를 물려받습니다. 시스템 환경 변수를 변경했다면 IDE를 완전히 종료한 뒤 다시 열어야 할 수 있습니다.

WSL, Docker 컨테이너, 가상 머신, SSH 원격 세션에는 별도의 네트워크 경계가 있습니다. 이 환경 안의 127.0.0.1은 보통 각 환경 자체를 가리키며 Clash가 실행 중인 호스트를 가리키지 않을 수 있습니다. WSL의 동작은 네트워크 모드와 시스템 설정에 따라서도 달라집니다. 먼저 호스트에 접근할 수 있는 주소와 수신 대기 범위를 확인하세요. LAN 접근을 허용해야 한다면 방화벽에서 접속 출처를 제한하고, 프록시 포트를 인터넷에 직접 노출하지 마세요.

5단계: SOCKS와 로그로 DNS, 규칙, 노드 문제 구분

로컬 HTTP 프록시에 연결되지만 특정 도메인 접속에 실패한다면 같은 혼합 포트에서 SOCKS 테스트도 해 보세요. 아래 명령은 socks5h를 사용해 curl이 대상 도메인을 로컬에서 먼저 해석하지 않고 SOCKS 프록시 측에 DNS 조회를 맡기도록 합니다.

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/ -o /dev/null

socks5://와 socks5h://는 curl이 도메인을 해석하는 위치가 다릅니다. 도메인을 받은 프록시는 커널의 DNS 및 규칙 설정에 따라 추가로 처리합니다. 따라서 SOCKS 테스트가 성공했다고 해서 컴퓨터 전체의 DNS가 정상이라고 단정할 수는 없습니다. 테스트 결과를 클라이언트 로그의 대상 도메인, 일치한 규칙, 정책 경로와 함께 살펴보세요.

브라우저의 보안 DNS 설정은 도메인 조회 경로를 바꿀 수 있지만, HTTP 프록시를 우회한다는 뜻은 아닙니다. ‘보안 DNS 사용’을 시스템 프록시가 작동하지 않는다는 증거로 바로 해석하지 마세요. 같은 도메인을 설정 변경 전후로 비교하고 실제 연결 기록을 함께 확인해야 DNS 방식을 조정할지 판단할 수 있습니다.

6단계: 프록시를 사용하지 않는 앱까지 연결해야 할 때 TUN 확인

TUN 모드는 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 받아 시스템 프록시를 읽지 않는 앱을 처리할 수 있습니다. 하지만 잘못된 포트를 바로잡는 기능은 아닙니다. 먼저 프록시를 명시한 명령이 정상 작동하도록 한 다음 TUN을 별도로 테스트하세요. 이렇게 하면 프록시 출구 문제와 가상 네트워크 어댑터의 트래픽 가로채기 문제를 구분할 수 있습니다.

1. 현재 클라이언트와 커널이 TUN을 지원하는지 확인하세요. mihomo를 사용하는 클라이언트와 구형 Clash 클라이언트는 제공하는 옵션이 다를 수 있으므로 인터넷에서 찾은 설정 블록을 모든 버전에 그대로 붙여 넣지 마세요.
2. 클라이언트 안내에 따라 서비스를 설치하거나 필요한 권한을 부여한 뒤 TUN을 켜세요. Windows 클라이언트는 서비스 모드나 관리자 권한이 필요할 수 있고, macOS는 권한을 요청할 수 있으며, Linux에서는 보통 네트워크 관리 권한이 필요합니다.
3. 로그에서 가상 네트워크 어댑터 생성 실패, 권한 부족, 라우팅 추가 실패 메시지가 있는지 확인하세요. 화면의 스위치가 켜져 있어도 관련 작업이 모두 성공했다고 볼 수는 없습니다.
4. 문제 해결 중에는 트래픽을 가로채는 방식을 하나만 남겨 두세요. 원래 설정을 기록한 뒤 시스템 프록시를 끄고 새 요청으로 TUN이 트래픽을 처리하는지 확인한 다음, 테스트가 끝나면 기존 조합으로 되돌리세요.
5. 다른 VPN, 가상 네트워크 어댑터, 네트워크 필터링 도구를 함께 사용 중이라면 하나씩 일시 중지해 비교하세요. 라우팅이나 네트워크 어댑터를 바로 삭제하지 마세요. 원격 연결에 의존하는 컴퓨터에서는 기본 경로를 성급하게 바꾸지 마세요.

mihomo의 tun.enable, auto-route, auto-detect-interface 및 DNS 가로채기 관련 설정은 각각 역할이 다릅니다. 클라이언트가 시작할 때 설정을 생성하거나 병합할 수 있어 구독 원본 파일을 수정해도 최종 적용값이 달라지지 않을 수 있습니다. 실행 중인 설정이나 클라이언트의 덮어쓰기 옵션을 확인하고, 커널을 다시 시작한 뒤 로그를 점검하세요.

TUN은 경로 제외, 프로세스 규칙, DNS 설정, 다른 네트워크 구성 요소의 영향도 받습니다. ‘켜면 모든 트래픽이 반드시 프록시를 거친다’고 단순하게 생각해서는 안 됩니다. 요청이 커널에 도달한 뒤 규칙에 따라 직접 연결되면 로컬 네트워크를 통해 나갈 수 있습니다.

설정 복원 및 최종 점검 순서

점검이 끝나면 실제로 필요한 진입 방식만 남겨 두세요. 임시로 변경한 환경 변수는 원래 값으로 복구해야 합니다. 아래 명령은 테스트 전에 해당 변수가 설정되어 있지 않았던 경우에만 사용하세요. 기존에 기업용 또는 개발 환경 프록시가 설정되어 있었다면 값을 바로 삭제하지 말고 기록해 둔 값으로 되돌리세요.

# PowerShell: 이번에 임시로 추가한 변수 삭제
Remove-Item Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue

# macOS / Linux: 이번에 임시로 추가한 변수 삭제
unset http_proxy https_proxy

• 먼저 로컬 진입 확인: 실제 혼합 포트를 지정해 요청이 커널에 도달하는지 확인합니다.
• 다음은 브라우저 확인: 시스템 프록시, 확장 프로그램, Firefox 개별 설정, 예외 목록을 점검합니다.
• 터미널은 별도로 확인: 현재 세션의 환경 변수, 프로그램 설정, 호스트 네트워크 경계를 점검합니다.
• 마지막으로 라우팅 확인: 규칙과 정책 경로를 살펴본 뒤 DNS를 조정하거나 TUN을 사용할지 결정합니다.

도움을 요청할 때는 운영체제 버전, 클라이언트 및 커널 버전, 실제 포트, 프록시를 명시한 명령의 결과, 같은 시간대의 관련 로그를 함께 제공하세요. 공유하기 전에 구독 주소, 노드 인증 정보, API 키, 개인 접속 기록을 삭제하세요. ‘Clash 시스템 프록시가 작동하지 않아요’라고만 설명하는 것보다 이런 정보가 원인을 좁히는 데 도움이 됩니다.

처음 설정하는 경우 시스템 프록시 가이드를 참고하세요. 요청이 커널에 도달하는 것을 확인했는데도 시간 초과가 계속된다면 연결 시간 초과 문제 해결을 확인해 보세요. 설정을 변경하기 전에 사본을 보관하고 한 번에 한 항목씩 바꿔야 어떤 설정이 결과에 영향을 주는지 파악할 수 있습니다.