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

시스템 프록시, 앱별 프록시, 규칙 기반 라우팅 구분하기

시스템 프록시를 켰다는 것은 운영체제에 프록시 설정이 등록됐다는 뜻일 뿐, 모든 프로세스가 이를 사용한다는 뜻은 아닙니다. 브라우저는 시스템 설정을 따를 수도 있지만 확장 프로그램이나 자체 설정이 이를 덮어쓸 수도 있습니다. 명령줄 프로그램은 보통 환경 변수나 별도 옵션을 설정해야 합니다. 연결이 Clash 코어에 들어간 뒤에도 모드와 규칙, 정책 그룹에 따라 최종 경로가 결정됩니다.

따라서 ‘출구 IP가 바뀌지 않았다’는 사실만으로 시스템 프록시가 작동하지 않는다고 단정할 수는 없습니다. 연결이 코어에 들어왔지만 DIRECT 규칙에 매칭됐을 수도 있고, 앱이 프록시를 완전히 우회했을 수도 있습니다. 문제를 확인할 때는 앱 설정과 클라이언트 연결 기록을 함께 살펴보세요. 웹페이지가 열리는지만 확인해서는 안 됩니다.

해당 필드를 지원하는 Clash 또는 mihomo 코어에서는 아래 설정으로 로컬에만 HTTP 및 SOCKS 프록시 포트를 엽니다. 기존 설정에 병합해서 사용해야 하며, 노드와 규칙은 포함되어 있지 않으므로 전체 구독 설정을 대신할 수 없습니다.

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

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. port와 socks-port를 별도로 사용하는 경우에는 프로토콜에 맞는 포트를 선택해야 합니다.
allow-lan: false는 로컬에서 테스트할 때 적합합니다. 이 컴퓨터의 브라우저를 점검하는 데 LAN 접속을 허용할 필요는 없습니다.
mode: rule은 규칙에 따라 트래픽을 분기합니다. 모드 이름만 확인하지 말고 대상 연결에 어떤 규칙이 적용됐는지 확인하세요.

1단계: 코어의 포트 리스닝과 프록시 직접 지정 요청 확인

시스템 프록시 설정을 거치지 않고 명령에서 프록시 포트를 직접 지정해 보세요. 이렇게 해도 연결되지 않는다면 브라우저 옵션을 계속 바꾸기보다 포트 리스닝 상태와 코어 실행 여부, 노드 연결을 먼저 확인해야 합니다.

7890 포트가 리스닝 중인지 확인

Windows PowerShell에서 다음 명령을 실행할 수 있습니다. 출력된 OwningProcess는 프로세스 ID입니다. 작업 관리자의 ‘세부 정보’ 탭에서 확인해 다른 프로그램이 사용 중인 포트를 Clash 포트로 착각하지 않도록 하세요.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOS에서는 lsof, Linux에서는 ss를 사용할 수 있습니다. 결과가 나오지 않으면 실제 포트가 다른지, 설정이 정상적으로 적용됐는지 먼저 확인하세요.

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

# Linux
ss -lntp 'sport = :7890'

curl에서 HTTP 프록시 직접 지정하기

Windows에서는 PowerShell 환경에 따라 같은 이름의 별칭이 명령 실행을 방해할 수 있으므로 curl.exe를 사용하세요. macOS와 Linux에서는 명령어를 curl로 바꾸면 됩니다. --noproxy ""는 기존 우회 목록이 이번 테스트에 영향을 주지 않도록 합니다.

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

먼저 127.0.0.1:7890에 연결되는지 확인하고, 다음으로 HTTPS CONNECT 터널이 만들어지는지 살펴본 뒤, 마지막으로 대상 사이트의 응답을 확인하세요. 예시 도메인은 연결 테스트용입니다. 실제 문제를 진단할 때는 문제가 발생하는 대상 주소로 테스트해야 합니다.

확인된 결과	우선 확인할 항목
로컬 7890 연결 거부됨	코어 실행 여부, 포트 일치 여부, 리스닝 주소에 접근 가능한지 확인합니다.
로컬 프록시에는 연결되지만 대상 연결 시간 초과	클라이언트 로그에서 대상, 규칙, 정책 그룹, 노드 출구를 확인합니다.
요청은 성공하지만 브라우저에서는 실패	브라우저의 프록시 설정 출처, 확장 프로그램, 우회 목록, 기존 연결을 확인합니다.
프록시를 직접 지정하면 성공하지만 일반 터미널 명령은 실패	환경 변수 설정 여부, 프로그램의 프록시 지원 여부, 도구 자체 설정이 환경 변수를 덮어쓰는지 확인합니다.

CONNECT 성공은 프록시 포트가 터널 요청을 수락했다는 뜻일 뿐, 특정 원격 노드를 거쳤다는 증거는 아닙니다. 최종 경로는 클라이언트 연결 상세 정보에 표시된 규칙과 경로를 함께 확인해야 합니다.

2단계: 브라우저의 프록시 설정 출처별로 점검

운영체제에 설정된 실제 주소부터 확인

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 주소와 포트를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 사용하는 네트워크 서비스 → ‘세부사항’ → ‘프록시’로 이동하세요. 운영체제 버전에 따라 메뉴 이름이 조금 다를 수 있습니다. 연결이 끊긴 Wi-Fi나 네트워크 어댑터가 아니라 현재 사용 중인 네트워크 서비스를 확인하는 것이 중요합니다.

로컬 프록시 주소에는 보통 127.0.0.1을 입력하고, 포트는 코어에서 리스닝 중인 포트와 일치시킵니다. 구독 URL을 프록시 서버 주소로 입력하면 안 됩니다.
PAC 자동 설정을 사용한다면 자동 설정 스크립트 주소와 적용 규칙을 확인하세요. PAC는 대상에 따라 직접 연결을 선택할 수 있으므로 모든 웹사이트가 같은 프록시 포트를 이용한다고 볼 수 없습니다.
클라이언트에서 시스템 프록시를 껐는데 다시 켜진다면 다른 프록시 프로그램이나 관리 정책이 설정을 변경하고 있을 수 있습니다. 먼저 설정을 관리하는 주체를 하나로 정리하세요.

브라우저 확장 프로그램과 자체 프록시 설정 확인

일반적인 데스크톱 환경에서 Chrome과 Edge는 보통 시스템 프록시를 사용하지만, 프록시 전환 확장 프로그램이나 시작 옵션, 기업 정책이 설정을 덮어쓸 수 있습니다. 프록시 관련 확장 프로그램을 잠시 사용 중지하고 브라우저를 완전히 종료한 뒤 다시 실행해 같은 주소로 테스트하세요. 시크릿 창에서도 확장 프로그램이 허용되어 있을 수 있으므로 시크릿 모드만으로 모든 확장 프로그램이 제외되는 것은 아닙니다.

Firefox에서는 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’에서 프록시 설정 출처를 확인할 수 있습니다. 운영체제 설정을 사용하려면 ‘시스템 프록시 설정 사용’을 선택하세요. ‘수동 프록시 설정’을 선택했다면 주소와 포트, ‘프록시를 사용하지 않을 주소’ 목록을 각각 확인해야 합니다.

회사에서 관리하는 기기라면 브라우저 관리 상태도 확인하세요. Chrome의 chrome://policy와 Edge의 edge://policy에서 적용된 정책을 확인할 수 있습니다. 관리 정책이 설정을 제한하는 경우 관리자에게 문의하고, 설정을 계속 덮어쓰지 마세요.

우회 목록과 기존 연결 확인

브라우저와 운영체제는 로컬 주소, 내부 도메인, 특정 IP 대역을 프록시에서 제외하는 경우가 많습니다. localhost, 라우터 관리 페이지, 회사 내부망 주소로 테스트하면 공용 인터넷 프록시의 작동 여부를 판단하기 어렵습니다. 설정을 바꾼 뒤에도 기존 연결이 계속 재사용될 수 있습니다. 같은 페이지를 연이어 새로고침하기보다 관련 탭을 닫고 브라우저를 완전히 종료한 다음 다시 실행해 테스트하세요.

3단계: 터미널에 http_proxy와 HTTPS_PROXY를 별도로 설정

클라이언트에서 시스템 프록시를 켜도 터미널의 모든 명령에 환경 변수가 자동으로 설정되지는 않습니다. 먼저 현재 세션에서 임시로 설정해 작동 여부를 확인한 뒤 필요하면 영구 설정하세요. HTTP 프록시 포트를 사용하는 경우 대상 사이트가 HTTPS여도 프록시 주소는 보통 http://127.0.0.1:7890으로 입력합니다. 변수 이름에 HTTPS가 들어간다고 주소를 https://로 바꾸면 안 됩니다.

macOS 및 Linux: 현재 셸에 임시 설정

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

curl --connect-timeout 10 --max-time 30 -v https://example.com/

# 테스트가 끝나면 이번에 설정한 값을 제거합니다
unset http_proxy https_proxy no_proxy

curl은 HTTP 프록시 환경 변수로 소문자 http_proxy만 인식합니다. 다른 프로그램은 대소문자 처리 방식이 다를 수 있습니다. 대문자 변수, ALL_PROXY, 도구 자체 설정도 함께 확인하세요. 한 그룹의 변수를 삭제해도 다른 설정이 남아 있으면 영향을 받을 수 있습니다.

Windows PowerShell: 현재 프로세스의 환경 변수

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

curl.exe --connect-timeout 10 --max-time 30 -v https://example.com/

# 테스트가 끝나면 이번에 설정한 값을 제거합니다
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY

이 설정은 현재 PowerShell과 이후 실행되는 하위 프로세스에만 적용되며, 이미 실행 중인 IDE, 터미널, 백그라운드 서비스에는 반영되지 않습니다. 기존 변수 값이 있다면 먼저 기록해 두고 테스트가 끝난 뒤 원래 값으로 복원하세요. 시스템 설정 화면에서 변수를 영구적으로 변경한 경우에는 새 값을 적용하려면 관련 앱을 다시 시작해야 하는 경우가 많습니다.

4단계: Git, WSL 및 도구별 프록시 설정 확인

curl은 정상인데 특정 도구만 실패한다고 해서 노드를 바로 문제로 볼 수는 없습니다. Git, 패키지 관리자, 런타임은 프록시 설정을 따로 저장하거나 환경 변수를 서로 다른 네트워크 라이브러리로 처리할 수 있습니다. 예를 들어 Git에서는 먼저 설정된 항목과 적용 범위를 확인하세요.

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

출력된 설정은 시스템, 사용자 또는 현재 저장소에 지정된 값일 수 있습니다. 오래된 설정임을 확인했다면 해당 범위에서 수정하세요. 모든 범위의 설정을 한꺼번에 지우면 안 됩니다. 한 번의 명령에만 프록시를 지정하려면 다음과 같이 실행할 수 있습니다.

git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

원격 주소가 SSH인 경우: [email protected]:git/git.git은 Git의 HTTP 프록시 경로를 사용하지 않으므로 SSH 자체의 연결 방식을 확인해야 합니다.
WSL 2: 기본 NAT 네트워크에서 Linux 내부의 127.0.0.1은 WSL 자체를 가리키므로 Windows 호스트와 같은 주소로 볼 수 없습니다. 미러링 네트워크 모드에서는 동작이 다르므로 현재 네트워크 모드에 맞춰 호스트에 접근할 수 있는 주소를 확인하세요.
컨테이너: 컨테이너 내부의 루프백 주소도 호스트 주소와 다릅니다. 네트워크 경계를 넘어 프록시에 연결해야 한다면 모든 네트워크에 공개하지 말고 리스닝 인터페이스와 방화벽 허용 대상을 제한하세요.
sudo 및 백그라운드 서비스: 환경 변수가 제거되거나 서비스가 별도 계정으로 실행될 수 있습니다. 대화형 터미널에서 테스트에 성공해도 서비스 프로세스가 같은 환경 변수를 사용하는 것은 아닙니다.

5단계: 요청이 코어에 들어온 뒤 규칙과 출구 확인

클라이언트의 연결 목록이나 실행 로그에서 대상 도메인과 테스트 시간을 기준으로 요청을 찾으세요. 대상 주소, 매칭된 규칙, 선택된 정책 그룹, 실제 연결 경로를 기록하는 것이 중요합니다. 클라이언트마다 화면 이름은 다르지만, 이 정보가 ‘켜짐’ 상태보다 실제 트래픽 경로를 파악하는 데 더 유용합니다.

DIRECT로 표시된다면 먼저 직접 연결 규칙에 매칭됐는지, 또는 정책 그룹에서 직접 연결을 선택했는지 확인하세요.
예상한 정책 그룹에 들어갔지만 시간 초과가 발생한다면 노드와 서버, 로컬에서 노드까지의 연결을 확인하세요.
관련 기록이 전혀 없다면 먼저 로그 수준과 필터 조건, 요청이 실제로 전송됐는지 확인한 뒤 앱의 프록시 설정을 다시 살펴보세요.

잠시 log-level: debug로 높이면 추가 단서를 얻을 수 있습니다. 재현을 마치면 info로 되돌리세요. 로그에는 도메인과 내부 IP, 구독 관련 정보가 포함될 수 있으므로 다른 사람에게 전달하기 전에 민감한 내용을 가리세요. 프록시 문제를 해결하려고 TLS 인증서 검증을 끄지 마세요. 인증서 오류는 인증서 체인, 시스템 시간, 네트워크 가로채기 여부를 각각 확인해야 합니다.

TUN 모드는 언제 사용해야 할까요?

앱에서 프록시 설정을 지원하지 않거나 더 많은 네트워크 트래픽을 처리해야 할 때 TUN 모드를 고려하세요. 시스템 프록시는 주로 앱이 프록시 포트를 직접 사용해야 작동합니다. TUN은 가상 네트워크 어댑터와 라우팅으로 트래픽을 처리하므로 적용 범위가 다릅니다. Clash Meta에서 발전한 mihomo는 관련 기능을 지원하지만, 실제 사용 가능 여부는 클라이언트 통합 여부와 시스템 권한, 실행 환경에 따라 달라집니다. 이름에 Clash가 들어간 모든 클라이언트가 같은 방식으로 동작한다고 볼 수는 없습니다.

mihomo 환경에서 아래 내용은 필드 간 관계를 보여 주는 예시일 뿐, 모든 기기에 적용할 수 있는 범용 설정은 아닙니다. 일부 클라이언트는 화면에서 선택한 옵션에 따라 해당 필드를 생성하므로, 화면 설정과 직접 작성한 설정이 서로 덮어쓰지 않도록 최종 적용 설정을 확인하세요.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

auto-route는 라우팅 처리와 관련된 설정으로, 보통 관리자 권한이나 해당 네트워크 권한이 필요합니다.
auto-detect-interface는 출구 인터페이스를 자동으로 감지합니다. 네트워크 어댑터나 가상 어댑터가 여러 개 있거나 VPN을 함께 사용한다면 실제 출구를 확인해야 합니다.
DNS 처리 여부는 DNS 모듈과 하이재킹 규칙, 시스템의 DNS 확인 경로를 별도로 점검해야 합니다. 위 네 가지 설정만으로 DNS까지 모두 처리되는 것은 아닙니다.
브라우저의 보안 DNS, IPv6, QUIC/UDP 트래픽은 실제 연결 경로를 기준으로 확인하세요. 모두 문제 원인이라고 단정해서는 안 됩니다.

결과에 따라 범위를 좁히고 설정을 한꺼번에 바꾸지 않기

가장 간단한 점검 순서는 다음과 같습니다. 리스닝 포트 확인 → 프록시를 직접 지정해 테스트 → 브라우저의 설정 출처 확인 → 터미널 환경 변수 확인 → 클라이언트의 규칙과 연결 경로 확인. 일반 프록시로 연결할 수 없는 앱에 한해서 TUN 사용을 검토하세요.

테스트할 때마다 운영체제와 클라이언트 이름, 실제 리스닝 포트, 실행한 전체 명령, 같은 시간대의 연결 기록 네 가지를 남기세요. 프록시를 직접 지정했을 때는 성공하지만 브라우저에서 실패한다면 브라우저를 점검하고, 터미널에서 옵션을 넣었을 때만 성공한다면 환경 변수와 도구 설정을 확인하세요. 이렇게 하면 ‘시스템 프록시가 작동하지 않는다’는 문제를 재설치만 반복하지 않고 검증 가능한 항목으로 나눠 진단할 수 있습니다.

설정 필드의 의미는 Clash 설정 필드에서 확인할 수 있습니다. 설정을 처음 가져오거나 프록시 모드를 선택한다면 입문 가이드의 순서에 따라 진행하세요.