문제 해결 예상 읽기 시간 12분

Clash 시스템 프록시가 작동하지 않을 때: 브라우저는 정상인데 터미널만 실패하는 경우

시스템 프록시, 브라우저별 설정, 터미널 환경 변수와 로컬 리스닝 포트를 차례로 점검하세요.

먼저 브라우저가 사용하는 프록시 경로 확인

“브라우저에서는 접속되지만 터미널에서는 실패한다”는 사실만으로 Clash 시스템 프록시 스위치가 고장 났다고 단정할 수는 없습니다. 브라우저와 명령줄 프로그램은 완전히 다른 네트워크 경로를 사용할 수 있습니다. 브라우저는 운영체제의 프록시 설정을 읽을 수도 있고, 브라우저 확장 프로그램이나 별도 프록시 설정, 자체 보안 DNS를 사용할 수도 있습니다. 반면 터미널 프로그램은 시스템 프록시를 무시하고 대상 주소에 직접 연결할 수 있습니다.

문제 해결의 첫 단계는 노드를 반복해서 바꾸는 것이 아니라 브라우저 트래픽이 실제로 어디를 거쳐 Clash로 들어오는지 확인하는 것입니다. 먼저 브라우저의 프록시 확장 프로그램과 별도 프록시 옵션을 잠시 끄고 Clash의 시스템 프록시만 활성화한 뒤 테스트 페이지에 다시 접속해 보세요. 확장 프로그램을 끈 뒤 브라우저도 연결되지 않는다면, 기존에 성공했던 트래픽은 시스템 프록시가 아니라 확장 프로그램을 통해 전달되었을 가능성이 큽니다.

그다음 Clash 클라이언트의 연결 기록을 확인하세요. 이전에 열어 보지 않은 도메인에 접속하고 연결 목록에 해당 도메인, 대상 주소, 적용된 규칙과 정책 그룹이 표시되는지 살펴봅니다. 브라우저에서는 접속에 성공했지만 Clash에 새 연결이 전혀 없다면 해당 요청이 현재 실행 중인 Clash 인스턴스로 들어오지 않은 것입니다. 흔한 원인으로는 브라우저가 다른 프록시를 사용하는 경우, 브라우저에서 별도 VPN을 활성화한 경우, 시스템에서 여러 프록시 클라이언트를 동시에 실행하는 경우, 브라우저가 아직 종료되지 않은 기존 연결을 재사용하는 경우가 있습니다.

브라우저와 터미널이 동일한 도메인과 프로토콜을 테스트하는지도 확인해야 합니다. 일반 웹페이지 접속, HTTPS API 요청, Git 저장소 연결, 소프트웨어 패키지 다운로드는 서로 다른 도메인·포트·규칙을 사용할 수 있습니다. 특정 웹페이지가 열린다고 해서 Git, 패키지 관리자 또는 원격 API의 대상도 같은 규칙으로 올바르게 처리된다는 뜻은 아닙니다.

Clash 로컬 리스닝 포트와 프로토콜 확인

터미널이 Clash를 통해 트래픽을 전달하려면 먼저 현재 리스닝 중인 로컬 프록시 포트에 연결해야 합니다. 클라이언트마다 기본값이 다를 수 있고 설정을 가져온 뒤 값이 덮어써질 수도 있으므로 포트가 항상 7890이라고 가정하지 마세요. 클라이언트의 포트 설정, 실행 로그 또는 현재 적용된 설정에서 실제 포트 번호를 확인해야 합니다.

일반적인 설정에는 HTTP 포트, SOCKS 포트 또는 mixed-port가 포함됩니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있어 브라우저, curl 및 기타 도구를 함께 사용할 때 편리합니다. 다음 내용은 구조를 보여 주는 예시일 뿐이며, 실제 점검에서는 클라이언트에 표시된 적용 설정을 기준으로 삼아야 합니다.

mixed-port: 7890
socks-port: 7891
allow-lan: false
mode: rule

설정에 포트가 적혀 있다고 해서 프로세스가 실제로 해당 포트를 리스닝하고 있다는 뜻은 아닙니다. 다른 프로그램이 포트를 사용 중일 수 있고, Clash 코어가 설정 로드 실패로 시작되지 않았을 수도 있습니다. Windows에서는 netstat 또는 PowerShell로 리스닝 상태를 확인하고, macOS와 Linux에서는 lsof 또는 ss를 사용할 수 있습니다.

netstat -ano | findstr 7890

lsof -nP -iTCP:7890 -sTCP:LISTEN

ss -lntp | grep 7890

리스닝 결과가 전혀 없다면 터미널 설정을 계속 수정하기보다 Clash 클라이언트에서 코어 실행 상태와 로그를 먼저 확인하세요. 포트를 다른 프로세스가 사용 중이라면 충돌하는 프로그램을 종료하거나 Clash 포트를 변경한 뒤 터미널의 프록시 주소도 함께 업데이트해야 합니다.

리스닝 상태를 확인했다면 curl에서 프록시를 명시적으로 지정해 보세요. 이 방법은 시스템 프록시와 환경 변수를 우회하므로 “터미널에서 로컬 포트까지”와 “Clash에서 대상 사이트까지”의 두 경로가 모두 작동하는지 빠르게 확인할 수 있습니다.

curl -I -x http://127.0.0.1:7890 https://example.com

curl -I --proxy socks5h://127.0.0.1:7891 https://example.com

첫 번째 명령은 HTTP 프록시로, 두 번째 명령은 SOCKS5로 테스트합니다. socks5h의 h는 대상 도메인 해석을 프록시가 담당한다는 뜻이며, 로컬 DNS 문제와 프록시 연결 문제를 구분하는 데 도움이 됩니다. 프록시를 명시했을 때 접속된다면 Clash 포트와 노드는 대체로 정상이며, 문제는 보통 시스템 프록시를 읽는 방식이나 터미널 환경 변수에 있습니다.

“connection refused”가 표시되면 먼저 포트와 코어 상태를 확인하세요. 오래 기다린 뒤 타임아웃이 발생한다면 방화벽, 노드 연결 상태와 규칙을 점검합니다. 프록시 인증 오류가 발생하면 사용 중인 클라이언트에 로컬 포트 인증 정보가 설정되어 있는지 확인하세요. 로그에서 요청이 Clash에 들어온 뒤 DIRECT 규칙으로 처리된 것이 보이면 규칙 순서와 최종 적용 정책 그룹도 확인해야 합니다.

터미널 프로그램에 프록시 환경 변수 설정

많은 명령줄 도구는 데스크톱 운영체제의 프록시 설정을 자동으로 읽지 않고 http_proxy, https_proxy, all_proxy 같은 환경 변수를 확인합니다. 변수 이름의 대소문자 처리와 지원 범위는 프로그램마다 다릅니다. 호환성 문제를 줄이려면 소문자와 대문자 형식을 모두 설정할 수 있지만, 같은 세션에 서로 충돌하는 주소를 남겨 두어서는 안 됩니다.

macOS와 Linux에서 임시 설정

Bash, Zsh 등의 Shell에서는 현재 터미널 세션에만 프록시 변수를 내보낼 수 있습니다.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

curl -I https://example.com

https_proxy는 HTTPS 대상에 사용할 프록시를 뜻하며 변수 값을 반드시 https://로 작성해야 한다는 의미는 아닙니다. 로컬 Clash 포트는 일반적으로 HTTP 프록시를 제공하므로 주소를 http://127.0.0.1:7890로 작성하는 경우가 많습니다. SOCKS를 일관되게 사용하려면 다음과 같이 설정할 수 있습니다.

export all_proxy=socks5h://127.0.0.1:7891
export ALL_PROXY=socks5h://127.0.0.1:7891

Windows CMD와 PowerShell에서 임시 설정

CMD에서는 set으로 현재 창의 환경 변수를 설정합니다.

set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890
curl.exe -I https://example.com

PowerShell에서는 현재 프로세스의 Env 범위에 값을 기록해야 합니다.

$Env:http_proxy = "http://127.0.0.1:7890"
$Env:https_proxy = "http://127.0.0.1:7890"
curl.exe -I https://example.com

PowerShell에서는 테스트할 때 curl.exe를 명시적으로 사용하세요. 이전 버전 환경의 명령 별칭 때문에 결과가 모호해지는 것을 방지할 수 있습니다. Invoke-WebRequest에는 프록시를 직접 지정할 수도 있습니다.

Invoke-WebRequest -Uri "https://example.com" -Proxy "http://127.0.0.1:7890"

남은 설정과 제외 목록 확인

변수를 수정하기 전에 현재 값을 출력해 이전 포트, 작동하지 않는 호스트 이름 또는 다른 프록시 프로그램의 주소가 남아 있는지 확인하세요. macOS와 Linux에서는 env | grep -i proxy를, PowerShell에서는 Get-ChildItem Env: | Where-Object Name -Match 'proxy'를 실행할 수 있습니다.

no_proxy 또는 NO_PROXY는 프록시를 거치지 않을 주소를 지정합니다. 대상 도메인이 실수로 제외 목록에 들어 있으면 프로그램은 직접 연결합니다. 일반적으로 localhost, 127.0.0.1 및 로컬 네트워크 서비스는 제외해도 되지만, 너무 넓은 접미사 규칙은 외부 도메인까지 함께 제외할 수 있습니다.

시스템 프록시, 도구 설정과 플랫폼별 차이 처리

시스템 프록시는 모든 프로그램이 반드시 따라야 하는 단일 전송 계층이 아닙니다. 운영체제가 제공하는 프록시 매개변수 모음에 가깝고, 이를 읽는지, 언제 읽는지, 어떤 프로토콜을 지원하는지는 애플리케이션마다 다릅니다. 브라우저는 대체로 시스템 설정을 읽지만 Git, npm, Python 패키지 관리자, 컨테이너 프로세스와 일부 Java 프로그램은 자체 설정을 사용하는 경우가 많습니다.

Windows 시스템 프록시와 WinHTTP

Windows 데스크톱 애플리케이션은 사용자 수준의 시스템 프록시를 읽는 경우가 많지만, 일부 시스템 구성 요소와 서비스는 WinHTTP 설정을 사용합니다. 두 설정은 완전히 동일하지 않습니다. 따라서 브라우저는 정상인데 서비스 계정으로 실행되는 도구만 실패하는 현상은 드물지 않습니다. 다음 명령으로 현재 WinHTTP 상태를 확인할 수 있습니다.

netsh winhttp show proxy

용도를 확인하지 않은 상태에서 사용자 프록시를 WinHTTP에 바로 가져오지 마세요. 해당 설정에 의존하는 시스템 구성 요소에 영향을 줄 수 있습니다. 먼저 특정 명령이 Clash에 직접 연결되는지 확인해 문제 범위를 좁힌 다음, 도구 자체 설정을 사용할지 시스템 수준 설정을 조정할지 결정하는 편이 안전합니다.

Git과 패키지 관리자의 별도 프록시

Git은 HTTP와 HTTPS 프록시를 별도로 저장할 수 있습니다. 환경 변수가 올바른데도 Git이 실패한다면 기존 설정이 남아 있는지 확인하세요.

git config --global --get http.proxy
git config --global --get https.proxy

현재 Clash HTTP 포트를 사용해야 한다면 다음과 같이 설정합니다.

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

Git의 별도 프록시가 더 이상 필요하지 않다면 값을 빈 문자열로 바꾸지 말고 해당 항목을 삭제하세요. npm, pnpm, pip, Maven과 Gradle도 각각 설정 출처가 다릅니다. 문제를 해결할 때는 도구 설정 파일, 환경 변수와 IDE 설정을 함께 확인해 하나의 요청이 여러 계층의 설정으로 중복 덮어써지지 않도록 해야 합니다.

프록시 프로토콜과 포트 일치 여부 확인

SOCKS 포트를 HTTP 프록시로 사용하거나 HTTP 포트를 SOCKS 주소로 지정하면 핸드셰이크가 실패합니다. Clash 클라이언트에서 포트 유형을 확인한 뒤 도구에서 해당 URL 스킴을 사용하세요. HTTP 프록시는 보통 http://127.0.0.1:포트로, SOCKS5는 socks5:// 또는 socks5h://로 작성합니다.

127.0.0.1과 localhost의 해석 차이도 주의해야 합니다. 일부 환경에서는 localhost가 IPv6 주소 ::1로 먼저 해석되지만 Clash는 IPv4만 리스닝할 수 있습니다. 문제를 확인하는 단계에서는 127.0.0.1을 직접 사용하면 변수를 줄일 수 있습니다.

TUN 모드, DNS와 격리 환경 확인

TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 가로채므로 일반적으로 각 터미널 프로그램이 시스템 프록시를 별도로 지원하지 않아도 됩니다. 그렇다고 TUN을 켜면 모든 명령이 자동으로 성공하는 것은 아닙니다. 가상 인터페이스 생성 권한, 라우팅 설정, DNS 가로채기, 프로세스 우회 규칙과 다른 VPN 소프트웨어가 결과에 영향을 줄 수 있습니다.

일반 시스템 프록시에서 curl로 포트를 명시하면 작동하지만 TUN을 켠 뒤 직접 요청이 실패한다면 Clash 로그에 해당 연결이 나타나는지 확인하세요. 기록이 전혀 없다면 라우팅이 TUN으로 들어가지 않은 것일 수 있습니다. 연결은 있지만 도메인 해석이 실패한다면 DNS 설정을 점검하고, 연결이 잘못된 정책 그룹으로 배정되었다면 규칙 매칭 결과를 다시 확인해 수정해야 합니다.

Clash Meta(일명 Mihomo)는 더욱 다양한 TUN, DNS와 규칙 기능을 지원하지만, 그래픽 클라이언트에서 관련 옵션을 제공하는지와 어떤 실행 권한을 사용하는지는 클라이언트 구현에 따라 다릅니다. YAML을 수정하기 전에 클라이언트가 시작할 때 설정을 다시 생성하는지 확인해 수동 변경 사항이 덮어써지지 않도록 하세요.

WSL, Docker, 가상 머신과 원격 개발 컨테이너는 별도로 처리해야 합니다. 이 환경에서 127.0.0.1은 보통 호스트가 아닌 해당 환경 자체를 가리킵니다. 호스트에서 Clash가 정상적으로 리스닝 중이어도 컨테이너 내부에서 127.0.0.1:7890에 접속하면 거부될 수 있습니다. 이 경우 가상 네트워크에서 호스트가 사용하는 주소를 지정하고, Clash가 로컬 네트워크 연결을 허용하며 해당 인터페이스를 포함한 주소에서 리스닝하는지 확인해야 합니다. 호스트 방화벽도 함께 점검하세요.

SSH로 원격 서버에 로그인한 뒤 실행하는 터미널 명령은 원격 호스트에서 동작합니다. 원격 호스트의 127.0.0.1 역시 로컬 컴퓨터를 가리키지 않습니다. 원격 명령에서 로컬 Clash를 사용하려면 명확한 SSH 포트 포워딩을 설정하거나 원격 환경에서 접근 가능한 프록시를 구성해야 하며, 로컬 환경 변수를 그대로 복사해서는 안 됩니다.

순서대로 Clash 터미널 프록시 원인 파악

효율적인 문제 해결은 시스템 프록시, 규칙, DNS와 노드를 동시에 수정하는 것이 아니라 계층별로 하나씩 검증하는 것입니다. 각 단계에서 한 가지 질문만 확인하고 결과를 기록하세요.

  1. 코어 실행 확인: Clash 클라이언트 상태와 시작 로그를 확인해 현재 설정이 정상적으로 로드되었는지 확인합니다.
  2. 포트 리스닝 확인: 적용된 설정에서 HTTP, SOCKS 또는 mixed-port를 확인한 뒤 시스템 명령으로 해당 포트가 리스닝 상태인지 확인합니다.
  3. 프록시 명시: curl -x 또는 --proxy를 사용해 로컬 포트에 직접 연결하고 시스템 프록시를 읽는 과정의 문제를 배제합니다.
  4. 연결 기록 확인: 요청이 Clash에 들어왔는지 확인하고 적용된 규칙, 정책 그룹, 노드와 오류 정보를 살펴봅니다.
  5. 터미널 변수 확인: proxy 관련 변수를 모두 출력하고 이전 주소와 충돌하는 값을 삭제한 다음 현재 세션에 올바른 포트를 설정합니다.
  6. 도구별 설정 확인: Git, 패키지 관리자, IDE와 런타임에 별도의 프록시 설정이 저장되어 있는지 확인합니다.
  7. 실행 경계 확인: 명령이 호스트, WSL, 컨테이너, 가상 머신 또는 원격 서버 중 어디에서 실행되는지 판단하고 해당 환경의 로컬 주소가 실제로 어디를 가리키는지 확인합니다.
  8. 마지막으로 TUN과 DNS 확인: 기본 포트 테스트가 통과한 뒤에만 가상 인터페이스, 라우팅과 도메인 해석을 분석합니다.

프록시를 명시한 테스트와 환경 변수 테스트는 모두 성공했는데 특정 도구만 계속 실패한다면 문제는 거의 해당 도구 자체에 있습니다. 이때는 Clash 노드를 계속 바꾸기보다 도구의 상세 로그를 활성화해 연결 대상 도메인, 읽어 들인 프록시 설정과 TLS 오류를 확인해야 합니다.

프록시를 명시한 테스트가 모두 실패한다면 Clash 측의 포트, 설정과 노드를 다시 확인하세요. 여러 대상 도메인을 각각 테스트하고 연결 기록에서 규칙 적용 결과를 비교할 수 있습니다. 일부 도메인만 실패하면 규칙, DNS와 대상 서비스에 집중하고, 모든 도메인에서 연결을 만들 수 없다면 로컬 리스닝, 코어 로그와 프록시 노드를 우선 점검하세요.

문제 해결이 끝나면 더 이상 사용하지 않는 임시 변수와 중복 설정을 정리하고 하나의 명확한 프록시 경로만 남기세요. 시스템 프록시는 데스크톱 애플리케이션에, 환경 변수는 터미널 세션에, 도구별 설정은 고정된 요구가 있는 프로그램에 적합하며 TUN은 더 많은 네트워크 트래픽을 가로채야 할 때 유용합니다. 현재 환경에 맞는 한 계층을 주된 진입점으로 선택하면 포트 변경과 설정 충돌로 인한 장애를 줄일 수 있습니다.

Clash 다운로드