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

먼저 구분하기: 코어 실행, 시스템 프록시, 앱 요청

클라이언트에 ‘실행 중’이라고 표시되어도 보통 프록시 코어가 시작됐다는 뜻일 뿐, 브라우저가 프록시를 사용하고 있다는 의미는 아닙니다. 노드 지연 시간 테스트에 성공해도 해당 테스트에 사용된 경로가 정상이라는 것만 확인할 수 있으며, 웹 요청이 같은 노드를 거쳤다는 보장은 없습니다. 문제를 파악할 때는 세 단계를 나눠 확인해야 합니다. 로컬 포트가 연결을 수신하는지, 앱이 요청을 해당 포트로 보내는지, 코어가 요청을 받은 뒤 어떻게 전달하는지 점검하세요.

Clash 및 Clash Meta(현재 이름: mihomo) 코어는 연결을 수신하고 전달합니다. 데스크톱 클라이언트의 ‘시스템 프록시’ 스위치는 보통 운영체제의 프록시 설정을 변경합니다. 두 기능은 서로 다릅니다. Chrome과 Edge는 대체로 시스템 프록시를 사용하고, Firefox는 프록시를 별도로 설정할 수 있습니다. 터미널 프로그램은 환경 변수나 자체 설정을 사용하는 경우가 많습니다.

클라이언트 이름, 코어 이름, 현재 모드, 로컬 수신 포트를 기록합니다.
매번 대상을 바꾸지 않도록 https://example.com/처럼 테스트 주소를 하나 정해 사용하세요.
클라이언트의 연결 목록과 로그를 열고 요청을 한 번 보낸 뒤 시간, 도메인, 규칙, 출구 정책을 확인합니다.
한 번에 한 항목만 변경하세요. 테스트가 끝나면 임시 설정을 원래대로 복구하고 변경 전후 결과를 기록합니다.

1단계: 로컬 프록시 포트가 연결을 수신하는지 확인

HTTP, SOCKS, 혼합 포트 구분하기

클라이언트 설정이나 실행 구성에서 port, socks-port, mixed-port를 확인합니다. 메뉴 이름은 클라이언트마다 다를 수 있으므로 실제 실행 중인 구성을 기준으로 판단하세요. 아래는 각 필드의 의미를 보여주는 예시입니다. 기존 구성에 포트를 세 개 모두 추가하거나 구독의 노드와 규칙을 덮어쓸 필요는 없습니다.

# 필드 예시: 현재 코어에서 실제로 적용 중인 구성을 기준으로 확인
port: 7890
socks-port: 7891
mixed-port: 7892
allow-lan: false

port: HTTP 프록시 포트입니다. HTTPS 사이트는 보통 HTTP CONNECT로 터널을 연결합니다.
socks-port: SOCKS 프록시 포트입니다. HTTP 프록시 포트로 입력하면 안 됩니다.
mixed-port: 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받습니다.

이 컴퓨터에서만 사용할 때는 주소로 127.0.0.1을 우선 사용하세요. 시스템 프록시는 7890을 가리키는데 코어는 7892에서만 수신 중이라면 흔한 포트 불일치 사례입니다. 로컬 연결 문제를 해결하려고 ‘LAN 연결 허용’을 켜지 마세요. 이 설정은 로컬 포트를 활성화하는 기능이 아닙니다.

수신 상태와 포트 사용 프로세스 확인

Windows에서는 PowerShell을 열어 먼저 포트를 테스트한 다음 수신 프로세스를 확인합니다. TCP 테스트에 성공해도 프로그램이 연결을 받고 있다는 뜻일 뿐입니다. 해당 프로세스가 현재 사용하는 프록시 코어인지도 확인해야 합니다.

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess
# 조회한 프로세스 ID를 입력하세요. 아래 1234는 예시입니다
Get-Process -Id 1234

macOS에서는 아래 명령어를 사용할 수 있습니다. Linux에서는 ss -lntp를 실행한 뒤 해당 포트를 찾으세요. 일부 프로세스 정보는 적절한 권한이 있어야 표시됩니다.

lsof -nP -iTCP:7890 -sTCP:LISTEN

로그에 address already in use가 표시되면 다른 프록시 클라이언트를 먼저 종료한 뒤 현재 코어를 다시 시작하세요. 수신 포트를 변경했다면 시스템 프록시, 브라우저 수동 프록시, 터미널 환경 변수도 함께 업데이트해야 합니다. 용도를 알 수 없는 프로세스를 바로 종료하거나 두 클라이언트가 같은 포트를 사용하도록 실행하지 마세요.

2단계: 명시적 프록시 테스트로 문제 범위 좁히기

먼저 시스템 프록시 설정을 우회하고 curl에 사용할 로컬 포트를 직접 지정하세요. 그러면 ‘앱이 프록시를 사용하지 않는 문제’와 ‘프록시 자체가 요청을 전달하지 못하는 문제’를 구분할 수 있습니다. Windows에서는 Windows PowerShell 5.1의 curl 별칭으로 인한 인자 차이를 피하려고 curl.exe를 사용하세요. macOS와 Linux에서는 curl을 사용하면 됩니다.

# Windows PowerShell: HTTP 또는 혼합 프록시 포트를 직접 지정
curl.exe -v --connect-timeout 5 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

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

# 실제 SOCKS 포트가 7891인 경우에만 이 명령어를 사용
curl -v --connect-timeout 5 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7891 https://example.com/

--noproxy ""는 이번 요청에서 우회 목록을 비워 기존 NO_PROXY의 영향을 막습니다. socks5h는 대상 호스트 이름의 DNS 조회를 프록시에 맡기고, socks5는 보통 로컬에서 먼저 조회합니다. 결과가 다르면 DNS 문제를 조사할 단서가 될 수 있지만, 한 번의 차이만으로 특정 DNS 서비스의 장애라고 단정할 수는 없습니다.

테스트 결과	의미와 다음 단계
127.0.0.1 연결이 거부됨	주소, 포트, 코어 실행 상태부터 확인하세요. 노드를 바꾸는 것은 우선순위가 아닙니다.
로컬 포트 연결에는 성공했지만 이후 시간 초과	해당 요청의 정책 그룹, 노드, DNS, 원격 연결 로그를 확인하세요.
명시적 프록시는 성공하지만 브라우저는 실패	시스템 프록시 설정, 브라우저 프록시 모드, 확장 프로그램을 먼저 확인하세요.
브라우저는 성공하지만 터미널의 일반 요청은 실패	환경 변수, 도구별 설정, 프로세스 시작 시점을 먼저 확인하세요.
일부 도메인에서만 실패	적용된 규칙, 우회 목록, 대상 사이트 응답, DNS 경로를 확인하세요.

HTTPS 테스트에서 200 Connection established가 보이면 보통 CONNECT 터널이 만들어졌다는 뜻입니다. 이후 TLS 연결과 웹 응답도 계속 확인해야 합니다. 403이 표시되어도 시스템 프록시가 작동하지 않는다고 단정할 수 없습니다. 대상 사이트의 접근 정책 때문일 수도 있습니다. 상태 코드 하나보다 전체 결과를 확인하는 편이 정확합니다.

3단계: 브라우저가 프록시를 사용하지 않을 때 시스템 설정과 확장 프로그램을 나눠 확인

Windows: 클라이언트 스위치뿐 아니라 현재 시스템 프록시 확인

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’으로 이동합니다. Windows 10에서도 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 확인할 수 있습니다.
프록시 주소가 현재 로컬 주소(예: 127.0.0.1)인지, 포트가 코어 설정과 일치하는지 확인하세요.
‘설정 스크립트 사용’이 켜져 있는지도 확인하세요. 스크립트 주소는 PAC 설정이며 규칙에 따라 일부 도메인을 프록시 없이 연결할 수 있습니다. 수동 프록시와 혼동하지 말고 각각 확인하세요.
프록시 예외 목록을 확인하세요. 대상 도메인이 목록에 있으면 브라우저가 프록시를 우회할 수 있습니다.

다른 프록시 도구의 자동 연결 기능을 먼저 끈 다음 현재 클라이언트의 시스템 프록시 스위치를 한 번 껐다 켜고 시스템 설정이 함께 바뀌는지 확인하세요. 회사에서 관리하는 기기는 조직 정책의 통제를 받을 수 있습니다. 설정이 자동으로 되돌아가면 관리자에게 문의하고 레지스트리를 반복해서 수정하지 마세요.

netsh winhttp show proxy는 WinHTTP 프록시 설정을 표시하며 Chrome이나 Edge가 사용하는 시스템 프록시 상태와는 다릅니다. WinHTTP가 직접 연결로 표시된다고 해서 브라우저 프록시가 꺼져 있다고 단정할 수 없습니다. 브라우저 접속을 위해 무턱대고 가져오기나 초기화 명령을 실행할 필요도 없습니다.

macOS: 현재 사용 중인 네트워크 서비스 확인

macOS 13 이상에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 연결된 Wi-Fi 또는 이더넷 → ‘세부사항’ → ‘프록시’로 이동합니다. 연결이 끊긴 인터페이스가 아니라 현재 사용하는 네트워크 서비스를 수정했는지 확인하세요. 웹 프록시(HTTP)와 보안 웹 프록시(HTTPS)를 모두 확인하고, 두 설정이 모두 로컬 HTTP 포트를 가리킨다면 포트가 클라이언트와 일치해야 합니다.

HTTPS 사이트에서 로컬 HTTP 프록시 포트를 사용하는 것은 정상입니다. 주소를 https://127.0.0.1로 바꿀 필요가 없습니다. 일반적인 Clash 로컬 HTTP 프록시는 클라이언트와 로컬 프록시 사이에서 TLS를 사용하지 않으며, HTTPS 암호화는 터널 안에서 이루어집니다.

Firefox와 프록시 확장 프로그램: 설정 경로는 한 번에 하나만 사용

Firefox에서는 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’으로 이동해 ‘시스템 프록시 설정 사용’이 선택되어 있는지 확인하세요. 수동 프록시를 사용한다면 주소, 포트, ‘프록시 사용 안 함’ 목록을 직접 점검하면 됩니다. Chrome과 Edge에서는 프록시 전환 확장 프로그램의 현재 프로필과 기업 정책에 따른 관리 여부도 확인하세요.

프록시 전환 확장 프로그램을 잠시 사용 중지한 뒤 다시 테스트하세요. 시크릿 창에서도 확장 프로그램이 모두 자동으로 사용 중지되는 것은 아닙니다.
브라우저를 완전히 종료한 뒤 다시 열어 설정 변경에도 기존 연결이 재사용되는 상황을 방지하세요.
테스트 요청을 보내면서 클라이언트의 연결 목록을 확인하세요. 기록이 없으면 진입 경로나 우회 설정 문제일 수 있지만, 페이지 캐시, 요청 미발생, 로그 필터도 함께 확인해야 합니다.
Linux 데스크톱에서는 모든 앱이 프록시 설정을 따르는 것은 아닙니다. 명시적 프록시 테스트가 성공한 뒤 각 앱이 지원하는 방식으로 설정하세요.

4단계: 터미널이 프록시를 사용하지 않을 때 환경 변수와 도구 설정 확인

시스템 프록시는 모든 프로세스에 강제로 적용되는 전달 계층이 아닙니다. 터미널의 curl, Git, 패키지 관리자는 환경 변수를 읽거나 각자 프록시 설정을 사용할 수 있습니다. 이미 열려 있는 터미널이나 IDE는 나중에 추가한 환경 변수를 받지 못할 수도 있습니다. 먼저 현재 세션에서만 테스트하고 전역 설정은 처음부터 적용하지 마세요.

macOS와 Linux: 현재 셸에서 설정

# 기존 프록시 변수를 확인합니다. 인증 정보가 포함된 출력은 공개하지 마세요
env | grep -iE '^(http|https|all|no)_proxy='

# 현재 터미널에서 적용됩니다. 포트는 실제 설정에 맞게 변경하세요
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# 이번 요청은 위에서 설정한 변수를 사용해야 합니다
curl -v --connect-timeout 5 --max-time 20 https://example.com/

# 점검이 끝나면 이번에 추가한 변수를 제거하세요
unset http_proxy https_proxy

https_proxy 값에 http://를 사용해도 모순이 아닙니다. 변수 이름은 대상 URL이 HTTPS임을, 변수 값은 프록시 서버에 연결하는 방식을 나타냅니다. curl에서 HTTP 프록시 변수는 대소문자에 따른 차이가 있으므로 여기서는 소문자 표기를 우선 사용하세요. 다른 도구가 어떤 변수를 지원하는지는 해당 도구의 문서를 확인해야 합니다.

Windows PowerShell: 프로세스 단위 변수 사용

# 현재 프로세스에 설정된 프록시 환경 변수를 확인
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|ALL|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 5 --max-time 20 https://example.com/

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

변수에 기존 값이 있었다면 기록해 두었다가 테스트 후 복구하고 바로 삭제하지 마세요. NO_PROXY에 대상 도메인이 포함되어 있는지 또는 값이 *로 설정되어 있는지 특히 확인하세요. 와일드카드 우회 설정은 이를 지원하는 도구가 모든 대상에 직접 연결하도록 만들 수 있습니다. ALL_PROXY를 설정했다면 오래된 SOCKS 포트가 남아 있지 않은지도 확인하세요.

Git, WSL, 컨테이너: 같은 프록시 주소를 공유한다고 가정하지 않기

아래 두 명령어로 Git 프록시 값과 설정 출처를 확인할 수 있습니다. 출처는 시스템, 사용자, 저장소 설정일 수 있으므로 문제를 해결할 때 해당 수준의 설정을 수정하세요. 사용자 설정만 삭제하고 현재 저장소 설정을 놓치지 않도록 주의해야 합니다. 출력에 사용자 이름, 비밀번호 또는 내부 주소가 포함되어 있다면 공유 전에 가리세요.

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

WSL, 컨테이너, 가상 머신 안의 127.0.0.1은 호스트 시스템을 가리키지 않을 수 있습니다. WSL은 NAT와 미러링 네트워크에서 동작이 다르고, 컨테이너도 보통 별도의 네트워크 공간을 사용합니다. 먼저 실행 환경과 호스트에 연결 가능한 주소를 확인한 뒤 수신 주소나 방화벽을 조정할지 판단하세요. 프록시를 모든 네트워크 인터페이스에 그대로 노출하지 마세요. SSH 형식의 Git 원격 주소도 HTTP 프록시를 설정했다고 해서 같은 경로를 자동으로 사용하지는 않습니다.

5단계: 요청이 Clash에 도달했다면 규칙, DNS, TUN 확인

연결 목록에 기록이 있다면 실제 출구 확인

클라이언트에 대상 도메인이 기록되어 있다면 이제 ‘시스템 프록시 스위치’가 아니라 전달 경로를 확인해야 합니다. 규칙 모드에서는 규칙을 순서대로 적용하며 DIRECT와 일치하면 직접 연결됩니다. 정책 그룹에서 예상한 프록시 노드가 아니라 직접 연결 항목이 선택되었을 수도 있습니다. 스위치를 반복해서 바꾸기보다 연결 상세 정보에서 규칙, 정책 체인, 대상 주소를 확인하세요.

대상 주소를 고정한 채 현재 규칙과 최종 선택된 출구를 기록합니다.
잠시 전역 모드로 전환하고 프록시 노드를 직접 선택한 뒤 같은 주소로 요청을 보냅니다.
전역 모드에서만 성공한다면 규칙 모드로 돌아가 해당 도메인의 규칙, 규칙 세트, 기본 규칙을 확인하세요.
테스트가 끝나면 원래 모드로 복구하세요. 전역 모드는 비교 테스트용이지 모든 문제의 장기적인 해결책은 아닙니다.

로그 수준을 잠시 debug로 높여 한 번 재현한 다음 info로 되돌릴 수 있습니다. connection refused는 거부된 대상이 로컬 포트인지 원격 서비스인지 확인하세요. i/o timeout은 DNS, 노드 연결, 대상 연결 중 어느 단계에서 시간 초과가 발생했는지 확인해야 합니다. 오류 메시지의 마지막 두 단어만 보고 판단하지 마세요.

DNS와 TUN: 함께 변경하지 말고 따로 확인

명시적 HTTP 프록시, SOCKS, 로컬 직접 연결, 브라우저 보안 DNS, TUN의 DNS 처리 방식은 서로 다른 경로를 사용할 수 있습니다. nslookup 성공은 해당 명령이 사용한 경로에서 이름을 조회할 수 있다는 뜻일 뿐, 코어도 같은 결과를 사용한다는 증거는 아닙니다. 요청에서 도메인 조회 오류가 발생하면 코어 로그와 dns 설정을 함께 확인하고 DNS 설정 안내를 참고하세요. 모든 상위 DNS 서버를 한꺼번에 바꾸지는 마세요.

TUN은 가상 네트워크 인터페이스로 지정된 트래픽을 처리합니다. 명시적 프록시 설정을 읽지 않는 프로그램에 유용하지만 ‘시스템 프록시 스위치의 강화판’은 아닙니다. 권한, 라우팅, DNS, 다른 VPN과의 호환성도 고려해야 합니다. 시스템 프록시와 TUN을 함께 켜면 테스트 요청이 다른 경로를 사용할 수 있습니다.

마무리: 점검 기록을 남기고 임시 설정 복구

문제를 문의할 때는 재현에 필요한 최소 정보를 제공하세요. 운영체제, 클라이언트와 코어 버전, HTTP/혼합 포트, TUN 사용 여부, 브라우저 이름, 명시적 curl 테스트 결과, 같은 시점의 연결 상세 정보를 포함하면 됩니다. 버전은 실제 클라이언트에서 확인하고 ‘최신 버전’이라고만 적지 마세요.

‘명시적 프록시는 성공했지만 브라우저는 실패’처럼 비교 결과를 구체적으로 기록하고, ‘연결이 안 됨’이라고만 쓰지 마세요.
로그에서 같은 요청을 찾을 수 있도록 구체적인 시간과 대상 도메인을 적으세요.
공유 전에 구독 링크, 노드 비밀번호, 요청의 Cookie, 인증 헤더, 민감한 쿼리 매개변수를 가리세요.
임시 변경한 모드, 로그 수준, 브라우저 확장 프로그램 상태, 환경 변수를 원래대로 복구하세요.

점검 순서는 그대로 유지하세요. 포트 수신 상태를 확인한 뒤 명시적 프록시를 테스트하고, 성공하면 브라우저와 터미널을 각각 설정합니다. 요청이 코어에 들어온 뒤에는 규칙, 노드, DNS를 확인하세요. 단계마다 결과를 확인할 수 있으므로 클라이언트 재설치는 첫 번째 조치가 아닙니다.