Clash 시스템 프록시가 작동하지 않을 때: 브라우저·터미널 점검 가이드

먼저 요청이 Clash에 전달되는지 확인하기

시스템 프록시 스위치를 켰다고 해서 모든 앱의 트래픽이 Clash로 전달되는 것은 아닙니다.브라우저는 확장 프로그램이 프록시를 따로 설정할 수 있고, 터미널은 보통 프록시를 직접 지정해야 합니다. PAC 규칙에서 대상 도메인이 직접 연결로 분류될 수도 있습니다. 요청이 코어에 도달했더라도 규칙에 따라 DIRECT로 연결될 수 있습니다. 노드를 계속 바꾸기보다 먼저 ‘프록시 미사용’과 ‘프록시 사용 후 직접 연결’을 구분하세요.

클라이언트에서 현재 설정과 로컬 수신 포트를 확인하세요. 이 문서에서는 HTTP 또는 혼합 프록시 예시로 127.0.0.1:7890을 사용하며, 실제 값은 설정에 따라 다릅니다.
클라이언트의 Connections(연결) 페이지를 열고 Logs(로그)에서 새 요청을 확인하세요. 필요하다면 로그 수준을 잠시 info로 낮추세요.
현재 시각을 기록한 다음 브라우저에서 네트워크 요청이 확실히 발생하는 페이지를 엽니다. 대상 도메인, 적용된 규칙, 프록시 경로를 확인하세요.
이후 아래에 소개된 명시적 프록시 명령으로 같은 대상에 접속해 보세요. 명령은 성공하고 브라우저만 실패한다면 구독을 바로 수정하지 말고 브라우저와 시스템 설정부터 확인하세요.

확인된 현상	먼저 확인할 항목	다음 단계
명시적 프록시 연결이 거부됨	코어가 실행되지 않거나 포트가 잘못되었거나 수신 중이 아님	로컬 포트와 프로세스 확인
명시적 프록시는 성공하지만 브라우저 연결 기록이 없음	확장 프로그램, 별도 프록시 설정, PAC 또는 우회 목록	브라우저와 시스템 설정 확인
연결 기록에 DIRECT가 표시됨	현재 모드와 규칙 순서	적용된 규칙과 정책 그룹 확인
프록시 노드 연결 후 시간 초과	노드, 원격 DNS 조회 또는 대상 사이트 연결	구체적인 오류를 확인하고 시스템 프록시 스위치 탓으로 돌리지 않기

로컬 포트 확인: 시스템 프록시 주소는 코어의 수신 포트와 일치해야 합니다

클라이언트 화면의 컨트롤 포트는 프록시 포트와 다릅니다. external-controller 설정은 제어 API용이므로 브라우저의 HTTP 프록시 주소로 사용할 수 없습니다. 일반적으로 port는 HTTP 프록시, socks-port는 SOCKS 프록시를 제공하고, mixed-port는 HTTP와 SOCKS 요청을 모두 받습니다.

예를 들어 7890과 7891은 흔히 쓰이는 설정값일 뿐, 고정된 표준은 아닙니다. 아래는 포트 설정의 관계를 설명하는 일부 YAML입니다. 노드, 구독 정보, 전체 규칙은 포함하지 않으므로 실제 연결에 사용할 수 있는 완전한 설정이 아닙니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Windows: 수신 포트와 시스템 설정 확인

PowerShell에서 다음 명령을 실행하세요. 첫 번째 명령은 포트가 수신 중인지 확인합니다. Windows 현재 사용자의 프록시 설정은 설정 화면을 직접 열어 확인해야 합니다.

Get-NetTCPConnection -State Listen -LocalPort 7890
Start-Process "ms-settings:network-proxy"

「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 주소가 127.0.0.1인지, 포트가 클라이언트 설정과 일치하는지 확인하고 ‘설정 스크립트 사용’이 켜져 있는지도 기록하세요. 첫 번째 명령에 결과가 없으면 클라이언트 코어가 실행 중인지 먼저 확인하세요. 다른 프로세스가 포트를 사용 중이라면 해당 프로세스가 무엇인지 확인해야 하며, 곧바로 Clash라고 단정해서는 안 됩니다.

macOS 및 Linux: 기본값을 추측하지 말고 수신 상태부터 확인

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 서비스→「세부사항」→「프록시」에서 HTTP, HTTPS, 자동 프록시 설정을 확인할 수 있습니다. Wi-Fi와 이더넷은 별개의 서비스이므로 네트워크를 바꾼 뒤 다시 확인하세요. Linux의 데스크톱 프록시 설정은 데스크톱 환경마다 다르며, 모든 앱이 데스크톱의 프록시 스위치를 읽는 것은 아닙니다.

브라우저 문제 해결: 확장 프로그램, 별도 설정, PAC를 각각 확인

Chrome 및 Edge: 먼저 확장 프로그램이 프록시를 제어하는지 확인

Chrome에서는 보통 「설정」→「시스템」→「컴퓨터의 프록시 설정 열기」에서 시스템 프록시를 확인합니다. Edge의 메뉴는 일반적으로 「설정」→「시스템 및 성능」→「시스템」에 있습니다. 버전에 따라 메뉴 이름이 조금 다를 수 있으므로 설정 페이지에서 ‘프록시’를 검색해도 됩니다.

프록시 전환 확장 프로그램의 현재 모드를 확인하세요. 다른 포트를 고정으로 사용하거나 특정 도메인을 직접 연결 목록에 넣었을 수 있습니다.
프록시를 변경하는 확장 프로그램을 모두 잠시 사용 중지하고 브라우저 프로세스를 전부 종료한 뒤 다시 실행해 테스트하세요. 시크릿 창에서도 확장 프로그램이 모두 꺼진다고 보장할 수 없습니다. 시크릿 모드에서 허용된 확장 프로그램은 계속 작동할 수 있습니다.
조직에서 관리하는 기기라면 chrome://policy 또는 edge://policy에서 프록시 정책을 확인하세요. 정책으로 잠긴 설정은 기기 관리자에게 변경을 요청해야 합니다.
브라우저 실행 인수에 --no-proxy-server, --proxy-server 또는 --proxy-pac-url이 포함되어 있는지 확인하세요. 이러한 인수는 실제 프록시 동작을 바꿀 수 있습니다.

Firefox: 별도의 프록시 설정을 사용 중인지 확인

「설정」→「일반」→「네트워크 설정」→「설정」으로 이동하세요. ‘시스템 프록시 설정 사용’을 선택한 뒤 테스트합니다. ‘수동 프록시 설정’을 사용하는 경우 HTTP, HTTPS 또는 SOCKS 주소와 포트를 각각 확인하세요. ‘프록시 사용 안 함’의 예외 목록도 확인하세요. 특히 개발 환경에서 추가한 도메인 접미사가 있는지 살펴보세요.

PAC: 브라우저가 Clash를 거칠지 먼저 결정합니다

PAC 스크립트의 FindProxyForURL은 URL과 호스트 이름에 따라 경로를 선택합니다. DIRECT를 반환하면 요청은 로컬 HTTP 프록시를 거치지 않습니다. PROXY 127.0.0.1:7890을 반환해야 해당 포트로 요청이 전달됩니다. 결과가 PROXY 127.0.0.1:7890; DIRECT라면 프록시를 사용할 수 없을 때 직접 연결로 전환될 수 있습니다. 구체적인 동작은 앱 구현에 따라 다릅니다.

PAC의 직접 연결과 Clash 규칙의 직접 연결은 서로 다른 단계에서 발생합니다.PAC는 먼저 프록시를 사용할지 결정하고, 요청이 코어에 전달된 다음에는 Clash의 rules가 경로를 결정합니다. 범위를 좁히려면 자동 설정 스크립트를 잠시 끄고 올바른 수동 HTTP 프록시만 설정해 테스트하세요. 변경 전 기존 값을 기록하고 테스트 후 복원하세요. 업무용 기기에서 조직이 배포한 PAC를 임의로 덮어쓰지 마세요.

터미널 문제 해결: 명시적 프록시로 비교 테스트

많은 명령줄 프로그램은 시스템 프록시 설정을 읽지 않습니다. 브라우저에서는 접속되지만 curl은 직접 연결된다고 해서 Clash가 작동하지 않는 것은 아닙니다. 환경 변수로 인한 혼선을 피하려면 먼저 명령 인수로 로컬 프록시를 명시하세요.

Windows PowerShell에서 테스트

Windows PowerShell 5.1에서는 curl 별칭이 다른 명령을 가리킬 수 있으므로 curl.exe를 사용하세요. 아래 명령은 예시 사이트에 접속하며, 로컬 HTTP 프록시를 강제로 사용하고 명령줄의 우회 목록으로 기존 NO_PROXY 설정이 영향을 주지 않도록 합니다.

curl.exe -v --connect-timeout 10 --max-time 30 --proxy http://127.0.0.1:7890 --noproxy localhost https://example.com/ --output NUL

여기서 --noproxy localhost는 localhost만 프록시에서 제외합니다. 테스트 대상인 example.com은 우회 목록에 포함되지 않습니다. 이 방식은 일부 구형 PowerShell에서 빈 문자열 인수를 전달할 때 발생하는 차이도 피합니다. 해당 도메인은 요청 경로를 설명하기 위한 예시일 뿐이며, 접속 여부가 모든 대상 사이트의 사용 가능 여부를 뜻하지는 않습니다.

macOS 및 Linux에서 테스트

curl -v --connect-timeout 10 --max-time 30 \
  --proxy http://127.0.0.1:7890 --noproxy "" \
  https://example.com/ --output /dev/null

상세 출력에서 로컬 연결 주소와 HTTPS 터널 협상 과정을 확인하세요. CONNECT example.com:443이 나타나면 curl이 HTTP 프록시에 터널 연결을 요청하는 중입니다. 200 Connection established를 받아도 이후 TLS와 웹 요청이 반드시 성공하는 것은 아닙니다. 최종 결과와 클라이언트 연결 기록을 함께 확인하세요.

Connection refused: 먼저 로컬 포트와 코어의 수신 상태를 확인하세요.
터널이 설정된 뒤 TLS 오류가 발생한다면 시스템 시간, 인증서 신뢰 설정, 다른 HTTPS 검사 프로그램의 사용 여부를 확인하세요. 인증서 검증을 건너뛰는 방법을 해결책으로 사용하지 마세요.
클라이언트에 노드 연결 시간 초과가 표시된다면 요청은 이미 프록시 경로에 진입한 상태입니다. 노드와 원격 연결을 이어서 확인하세요.

환경 변수와 앱 설정: 변경 사항은 해당 프로세스에만 적용됩니다

명시적 프록시 테스트가 성공하면 프록시가 필요한 터미널 프로세스에 환경 변수를 설정하세요. curl에서 HTTPS 대상에 접속할 때는 https_proxy를 사용할 수 있습니다. 변수 값의 http://는 ‘클라이언트에서 프록시까지’의 프로토콜을 뜻하므로 https://로 바꿀 필요가 없습니다. 도구마다 지원하는 변수와 우선순위는 다를 수 있습니다.

현재 설정값부터 확인

# PowerShell: 현재 프로세스의 프록시 관련 환경 변수 확인
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'

# macOS / Linux
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

남아 있는 포트나 이전 프록시 주소, NO_PROXY 또는 no_proxy 설정을 중점적으로 확인하세요. 예를 들어 NO_PROXY=*는 해당 규칙을 지원하는 도구에서 모든 프록시를 우회하게 합니다. 도메인 접미사 일치 규칙은 각 도구의 문서를 확인하세요. curl은 HTTP 프록시 환경 변수에 특별한 보안 처리를 적용하므로 POSIX 셸에서는 소문자 http_proxy를 우선 사용하고 대문자 HTTP_PROXY만 설정하지 마세요.

먼저 현재 터미널에서만 설정하고, 확인 후 영구 적용

# PowerShell: 현재 프로세스와 이후에 시작하는 하위 프로세스에 적용
$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"

# macOS / Linux: 현재 셸과 이후에 시작하는 하위 프로세스에 적용
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

위 설정은 이미 실행 중인 IDE, 백그라운드 서비스, 다른 터미널 창에 자동으로 적용되지 않습니다. 환경 변수가 제대로 설정됐는지 확인하려면 대상 프로그램을 새로 실행하거나 현재 터미널에서 직접 실행하세요. sudo를 사용하면 환경 변수가 제거될 수 있습니다. WSL, 컨테이너, 원격 SSH 세션의 127.0.0.1도 호스트의 주소와 같다고 단정하지 말고 네트워크 경계와 실제로 연결 가능한 주소를 확인하세요.

Git에 별도의 프록시 설정이 있을 수도 있습니다. 다음 명령으로 설정 출처를 확인하세요. 저장소나 조직의 설정을 덮어쓰지 않도록 수정 전에 먼저 읽어보세요.

git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'

요청이 코어에 도달한 뒤: Rule, DIRECT, 정책 그룹 확인

Connections에서 대상 요청을 찾아 도메인, 일치한 규칙, 규칙의 대상, 프록시 경로를 확인하세요. 필드 이름은 클라이언트마다 다를 수 있지만 판단 기준은 같습니다. 경로가 DIRECT라면 해당 요청은 직접 연결로 선택된 것입니다. 정책 그룹과 실제 노드가 표시된다면 그 노드를 기준으로 이어서 점검하세요.

모드 확인:Rule은 규칙에 따라 트래픽을 분기하고, Direct 모드는 직접 연결하며, Global은 전역 정책을 사용합니다. 시스템 프록시 스위치는 이 세 가지 모드와 별개입니다.
규칙 순서 확인:규칙은 일반적으로 순서대로 매칭됩니다. 앞에 있는 도메인, IP 또는 규칙 세트 항목이 먼저 적용될 수 있으며, 마지막의 MATCH는 이미 적용된 규칙을 덮어쓰지 않습니다.
그룹 내 선택 확인:규칙이 ‘프록시’라는 이름의 정책 그룹을 가리키더라도 그룹 안에서 DIRECT가 선택되어 있을 수 있습니다. 그룹 이름만으로 실제 트래픽이 프록시를 거친다고 볼 수는 없습니다.
도메인 정보 확인:앱이 IP 주소로 직접 연결하거나 DNS 캐시를 사용하거나 다른 방식으로 트래픽을 가로채면 코어가 규칙 매칭에 사용할 수 있는 정보가 달라질 수 있습니다. 도메인 규칙이 적용되지 않았다는 이유만으로 규칙 세트가 작동하지 않는다고 단정하지 마세요.

필요하다면 잠시 Global 모드로 전환하고 정상 작동이 확인된 노드를 선택해 비교 테스트하세요. Global 모드에서는 되지만 Rule 모드에서 직접 연결된다면 규칙과 그룹 내 선택을 중점적으로 살펴보세요. 테스트 후에는 원래 모드로 복원하세요. 노드나 규칙을 바꿔도 기존 TCP 및 HTTP/2 연결은 자동으로 다시 설정되지 않을 수 있으므로 새 경로를 확인하려면 앱에서 연결을 다시 시작해야 합니다.

시스템 프록시로 처리되지 않는 트래픽은 TUN을 검토하세요

시스템 HTTP 프록시는 모든 UDP 트래픽을 처리하지 않으며, 자체 네트워크 스택을 사용하는 게임이나 명령줄 도구, 기타 앱의 트래픽까지 모두 다루는 것도 아닙니다. Clash Meta(mihomo)의 TUN 기능은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리합니다. 시스템 프록시와 적용 범위가 다르지만 플랫폼 권한, 라우팅, DNS 설정, 코어 구성에 따라 달라집니다.

로컬 포트를 확인하기도 전에 TUN을 켜고 DNS를 바꾸고 전역 모드까지 전환하지 마세요. 결과는 달라질 수 있어도 어떤 변경이 효과를 냈는지 알 수 없습니다. 대상 앱이 프록시를 지원하지 않는 것이 확실하다면 클라이언트 안내에 따라 TUN에 필요한 서비스나 관리자 권한을 확인하고 VPN 또는 다른 가상 네트워크 어댑터와의 충돌을 점검하세요. 브라우저의 보안 DNS는 이름 조회 경로에 영향을 주지만, 이를 ‘브라우저가 HTTP 프록시를 우회한다’는 뜻으로 단순화할 수는 없습니다.

재테스트와 기록: 같은 대상으로 변경 전후 비교

클라이언트 이름과 실제 버전, 코어 버전, 운영체제 버전, HTTP 또는 혼합 프록시 포트를 기록하세요. ‘최신 버전’이라고만 적지 마세요.
한 번에 하나만 변경하고 테스트 도메인, 요청 도구, 선택한 노드를 동일하게 유지하세요. 테스트 시간도 기록하세요.
브라우저 결과, 명시적 프록시를 사용한 curl 결과, 연결 페이지의 적용 규칙과 실제 프록시 경로를 함께 저장하세요.
출구 IP를 확인해야 한다면 신뢰할 수 있는 서비스를 사용하고 연결 기록과 교차 확인하세요. 한 페이지에 표시되는 위치 정보는 늦게 갱신될 수 있으므로 경로를 입증하는 자료를 대신할 수 없습니다.
점검 정보를 공유하기 전에 구독 주소, 액세스 토큰, 노드 인증 정보, 개인 접속 기록을 삭제하세요. 명령의 상세 출력도 먼저 확인해야 합니다.

마지막으로 문제를 명확한 단계에 귀속할 수 있어야 합니다. 로컬 포트가 수신 중이 아님, 앱이 프록시를 사용하지 않음, PAC 또는 예외 목록에서 우회함, 규칙에서 직접 연결을 선택함, 프록시 경로 연결에 실패함 중 하나로 정리하세요. 명시적 프록시 테스트, 브라우저 설정, 코어 기록이 서로 들어맞는다면 클라이언트를 반복해서 재설치하며 원인을 추측할 필요가 없습니다. 기본 설정 순서는 입문 가이드에서 확인하고, 규칙과 DNS는 고급 설정에서 더 살펴보세요.