시스템 프록시는 켰는데 작동하지 않을 때? 브라우저와 터미널을 나눠 점검하는 완벽한 순서

먼저 문제가 발생한 계층을 확인하세요

“시스템 프록시가 켜져 있음”은 Clash 클라이언트가 운영 체제의 프록시 주소를 로컬 수신 포트로 바꾸려고 했다는 뜻일 뿐, 모든 앱이 이 설정을 읽는다는 의미는 아닙니다. Chrome, Edge, Safari는 일반적으로 시스템 프록시를 따르지만 Firefox는 자체 연결 설정을 사용할 수 있습니다. curl, Git, npm, Python 패키지 관리자와 대부분의 터미널 프로그램은 네트워크에 직접 연결할 수도 있습니다. 문제를 점검할 때는 노드를 반복해서 바꾸기보다 브라우저, 터미널, Clash 코어를 먼저 구분해야 합니다.

시작하기 전에 클라이언트에서 다음 세 가지를 확인하세요. 구성 파일이 활성화되어 있는지, 정책 그룹에 사용할 수 있는 노드가 있는지, 코어가 실행 중인지 확인합니다. 클라이언트마다 메뉴 이름은 조금씩 다르지만 일반적인 경로는 「구성」→「현재 구성」, 「프록시」→「정책 그룹」, 「설정」→「시스템 프록시」입니다. 로그 페이지에 새 연결이 전혀 없다면 문제는 대개 앱과 로컬 프록시 포트 사이에 있습니다. 연결 기록은 있지만 시간 초과, 규칙 오류 또는 노드 실패가 표시된다면 구성과 원격 노드를 확인하세요.

네 가지 증상으로 빠르게 원인 좁히기

증상	우선 확인할 항목	흔한 원인
모든 웹페이지를 열 수 없음	Clash 수신 포트와 시스템 프록시 주소	코어가 실행되지 않았거나 포트가 잘못 입력되었거나 다른 프로세스가 포트를 사용 중임
브라우저는 되지만 터미널은 실패함	터미널 환경 변수와 프로그램 자체 설정	명령줄 도구가 시스템 프록시를 읽지 않음
브라우저에서 일부 사이트만 실패함	규칙 적용, 우회 목록 및 확장 프로그램	도메인이 직접 연결되거나 프록시 확장이 시스템 설정을 덮어씀
TUN을 켜면 되지만 시스템 프록시 모드에서는 실패함	앱이 HTTP 또는 SOCKS 프록시를 지원하는지 여부	앱이 시스템 프록시를 우회해 직접 연결함

Clash 수신 포트와 시스템 프록시 주소 확인

Clash에서 흔히 사용하는 로컬 수신 방식은 HTTP 포트, SOCKS5 포트, mixed-port입니다. 예전 구성에서는 HTTP를 7890, SOCKS5를 7891로 설정하는 경우가 많았습니다. mihomo 구성에서는 mixed-port: 7890만 활성화해 하나의 포트로 HTTP와 SOCKS5 요청을 함께 받기도 합니다. 포트 번호는 고정되어 있지 않으므로 최종적으로는 클라이언트의 「설정」→「포트 설정」 또는 현재 구성에 표시된 실제 값을 기준으로 확인해야 합니다.

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

이 구성은 프록시가 로컬 호스트의 127.0.0.1:7890에서만 수신한다는 뜻입니다. 시스템 프록시의 서버 주소도 127.0.0.1을 가리켜야 하며, HTTP와 HTTPS에는 같은 mixed 포트를 입력할 수 있습니다. 구독 노드의 원격 주소를 운영 체제 프록시 설정에 입력하지 말고, Clash의 제어 포트를 트래픽 포트로 착각하지도 마세요.

Windows 11 확인 경로

「설정」→「네트워크 및 인터넷」→「프록시」를 엽니다.
「프록시 서버 사용」이 켜져 있는지 확인합니다.
주소가 127.0.0.1인지, 포트가 Clash의 현재 수신 포트와 일치하는지 확인합니다.
클라이언트가 자동 구성 스크립트를 사용한다면 「설정 스크립트 사용」에 입력된 주소가 여전히 유효한지 확인합니다.
시스템 프록시를 전환한 후 문제가 발생한 앱을 완전히 종료했다가 다시 열어 기존 연결 풀을 사용하지 않도록 합니다.

macOS 확인 경로

「시스템 설정」→「네트워크」를 엽니다.
현재 사용 중인 Wi-Fi 또는 이더넷 연결을 선택합니다.
「세부사항」→「프록시」로 이동합니다.
웹 프록시 HTTP, 보안 웹 프록시 HTTPS, SOCKS 프록시의 주소와 포트를 확인합니다.
Clash 클라이언트가 설정을 관리한다면 다른 프록시 도구가 기록한 이전 포트를 동시에 유지하지 마세요.

포트가 실제로 수신 중인지 직접 테스트

Windows에서는 PowerShell에서 다음 명령을 실행할 수 있습니다. Listen이 표시되거나 TCP 연결이 수립되면 로컬 포트가 열려 있다는 뜻입니다. 연결에 실패하면 먼저 코어를 재시작하거나 포트 충돌을 해결하세요.

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue

macOS와 Linux에서는 lsof로 수신 프로세스를 확인할 수 있습니다.

lsof -nP -iTCP:7890 -sTCP:LISTEN
nc -vz 127.0.0.1 7890

수신 프로세스가 현재 사용 중인 Clash 또는 mihomo 프로세스가 아니라면 포트를 점유한 이전 클라이언트를 먼저 종료한 뒤 현재 클라이언트를 시작하세요. 또는 「설정」→「포트 설정」에서 사용하지 않는 포트(예: 7892)로 변경한 다음 시스템 프록시를 다시 켜 운영 체제에 새 값을 적용할 수 있습니다.

브라우저가 작동하지 않을 때 항목별 점검

Chromium 계열 브라우저는 일반적으로 운영 체제의 프록시를 읽지만, 브라우저 확장 프로그램과 기업 정책, 독립 사용자 설정에 따라 실제 경로가 달라질 수 있습니다. 점검할 때는 먼저 일반 창을 열고 프록시 전환을 담당하는 확장 프로그램을 잠시 비활성화한 뒤 대상 페이지에 접속하세요. 시크릿 창이 모든 확장 프로그램을 비활성화하는 것은 아니므로 확장 프로그램 관리 페이지에서 상태를 확인해야 합니다.

Chrome 및 Edge

Chrome에서는 「설정」→「시스템」→「컴퓨터의 프록시 설정 열기」로 이동해 현재 시스템의 프록시 페이지로 연결되는지 확인합니다.
Edge에서는 「설정」→「시스템 및 성능」→「컴퓨터의 프록시 설정 열기」로 이동합니다.
브라우저 프로세스를 완전히 종료한 뒤 다시 엽니다. 탭 하나만 닫아서는 기존 장기 연결이 정리되지 않습니다.
Clash 로그에서 대상 도메인을 기준으로 적용된 규칙을 확인합니다. 기록에 DIRECT가 표시되면 브라우저 포트를 바꾸지 말고 규칙 순서를 점검하세요.
브라우저가 조직 정책으로 관리된다면 주소 표시줄에 chrome://policy 또는 edge://policy를 입력해 고정 프록시 정책이 있는지 확인합니다.

Firefox의 독립 연결 설정

Firefox는 시스템 프록시를 따르지 않을 수 있습니다. 「설정」→「일반」→「네트워크 설정」→「설정」으로 이동하면 일반적으로 프록시 사용 안 함, 자동 감지, 시스템 프록시 설정 사용, 수동 프록시 설정의 네 가지 상태가 있습니다. Clash 시스템 프록시를 따르려면 「시스템 프록시 설정 사용」을 선택하고, 별도로 테스트하려면 수동 설정을 선택해 127.0.0.1과 실제 포트를 입력하세요.

SOCKS5를 수동으로 설정할 때 프록시 주소에는 127.0.0.1, 포트에는 Clash의 SOCKS 또는 mixed 포트를 입력하고 SOCKS v5를 선택합니다. 「SOCKS v5 사용 시 DNS 조회를 프록시로 전달」 옵션이 있다면 진단 단계에서 켜는 것이 좋습니다. 도메인 조회도 같은 경로로 처리할 수 있기 때문입니다.

우회 목록 확인

시스템 프록시는 일반적으로 localhost, 127.0.0.1, 로컬 네트워크 주소 또는 사용자가 직접 추가한 도메인을 우회합니다. Windows 프록시 페이지의 「다음 항목으로 시작하는 주소에는 프록시 서버 사용 안 함」과 macOS 프록시 페이지의 「다음 호스트 및 도메인에 대한 프록시 설정 무시」 옵션은 일치하는 대상을 직접 연결하게 만듭니다.

특정 도메인이 Clash 로그에 계속 나타나지 않는다면 먼저 우회 목록에서 해당 도메인과 와일드카드 항목을 제거한 뒤 브라우저를 다시 시작하세요. 라우터 주소 192.168.1.1처럼 로컬 네트워크 관리 페이지는 일반적으로 계속 직접 연결해야 하므로, 테스트를 위해 모든 로컬 주소 예외를 삭제하지는 마세요.

터미널이 기본적으로 시스템 프록시를 사용하지 않을 때

터미널은 명령을 실행하는 환경일 뿐입니다. 프록시 사용 여부는 curl, Git, npm, pip 등 각 프로그램이 결정합니다. 많은 명령줄 도구가 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 읽지만, 소문자 변수만 읽거나 자체 구성 파일을 우선하는 프로그램도 있습니다. 따라서 브라우저가 이미 작동하더라도 터미널은 별도로 설정해야 합니다.

macOS, Linux 및 Bash, Zsh

현재 터미널 세션에만 적용되는 HTTP 프록시 설정은 다음과 같습니다. 프록시 주소의 http://는 터미널 프로그램이 HTTP 프록시 프로토콜로 로컬 포트에 연결한다는 뜻이며, 대상 웹사이트가 HTTP만 사용한다는 의미는 아닙니다.

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

SOCKS5를 사용할 때는 이 변수를 지원하는 프로그램에 다음과 같이 설정할 수 있습니다.

export ALL_PROXY="socks5h://127.0.0.1:7890"
export all_proxy="$ALL_PROXY"

socks5h의 h는 SOCKS 프록시 측에서 도메인을 해석한다는 뜻으로, 로컬 DNS 경로와 프록시 경로가 달라지는 문제를 줄일 수 있습니다. 모든 프로그램이 이 형식을 인식하는 것은 아니므로 지원하지 않으면 프로그램 자체의 프록시 옵션을 사용하세요.

Windows PowerShell

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

이 변수는 현재 PowerShell 창과 해당 창에서 시작한 하위 프로세스에만 영향을 줍니다. 창을 닫으면 사라지므로 점검에 적합합니다. 삭제하려면 다음을 실행하세요.

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

Windows 명령 프롬프트

set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
set NO_PROXY=localhost,127.0.0.1,::1

마찬가지로 임시 진단만 필요하다면 영구 환경 변수를 바로 사용하지 마세요. 이전 포트가 시스템 수준 변수에 기록되면 Clash가 나중에 다른 포트로 변경되어도 새 터미널 프로그램은 계속 이전 주소에 연결합니다. 그 결과 “시스템 프록시는 올바르지만 명령은 계속 실패하는” 현상이 발생할 수 있습니다.

curl로 프록시, DNS, 대상 사이트를 분리해 테스트하기

curl은 시스템 프록시나 현재 환경 변수에 의존하지 않고 프록시를 직접 지정할 수 있습니다. 먼저 명시적인 HTTP 프록시로 요청을 보내고 -v를 추가해 연결 과정을 확인하세요.

curl -v --proxy http://127.0.0.1:7890 https://example.com/

출력에 먼저 127.0.0.1:7890 연결이 나타나고 Clash 로그에 example.com 기록이 추가되면 터미널에서 Clash로 이어지는 경로가 정상입니다. Connection refused가 표시되면 우선 포트와 코어를 확인하세요. 로컬 연결은 성공했지만 이후 시간 초과가 발생한다면 정책 그룹의 노드, 규칙 적용, 원격 연결을 확인합니다.

SOCKS5 테스트는 다음과 같이 실행할 수 있습니다.

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

그다음 프록시를 지정하지 않은 명령으로 비교 테스트를 진행합니다.

curl -v https://example.com/

명시적 프록시는 성공하지만 일반 명령이 실패한다면 Clash 자체는 작동하며 문제는 환경 변수나 프로그램 설정에 집중됩니다. 두 명령 모두 실패하면 로그를 계속 확인하세요. 명시적 프록시 요청이 로그에 들어오지 않으면 포트 오류일 가능성이 높고, 로그에 들어온 뒤 연결이 실패하면 구성, 규칙 또는 노드 경로 문제입니다.

환경 변수의 실제 값 확인

macOS와 Linux에서는 다음을 실행할 수 있습니다.

env | grep -i proxy

PowerShell에서는 다음을 실행할 수 있습니다.

Get-ChildItem Env: | Where-Object Name -Match "PROXY"

이전 주소, 이전 포트, 중복 변수를 중점적으로 확인하세요. 예를 들어 HTTPS_PROXY는 127.0.0.1:7890을 가리키지만 소문자 https_proxy는 여전히 127.0.0.1:1080을 가리킬 수 있습니다. 프로그램마다 읽는 순서가 달라 중복 값이 일관되지 않은 결과를 만들 수 있으므로, 진단 단계에서는 대소문자 변수의 값을 동일하게 유지하세요.

Git, npm 및 기타 도구의 독립 프록시 설정

환경 변수가 올바른데 특정 도구만 실패한다면 해당 도구의 전용 설정을 확인하세요. 전용 설정은 시스템 프록시보다 안정적인 경우가 많지만 포트가 바뀌면 함께 업데이트해야 합니다.

Git

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
git config --global --get-regexp "http.*proxy"

전역 프록시를 해제하려면 다음을 실행하세요.

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

저장소 수준의 설정에 별도 프록시가 있다면 저장소 안에서 git config --local --get-regexp "http.*proxy"를 실행하세요. 로컬 설정은 전역 설정보다 우선하므로 특정 저장소만 연결에 실패하는 원인이 될 수 있습니다.

npm

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
npm config get proxy
npm config get https-proxy

설정을 정리할 때는 다음을 사용하세요.

npm config delete proxy
npm config delete https-proxy

영구 설정 전에 일회성 명령을 우선 사용하세요

점검 단계에서는 먼저 curl의 --proxy, 프로그램 명령줄 옵션 또는 현재 세션의 환경 변수를 사용하세요. 경로가 안정적으로 작동하는 것을 확인한 뒤 ~/.zshrc, ~/.bashrc 또는 도구 설정에 저장할지 결정하는 것이 좋습니다. 이렇게 하면 클라이언트 포트가 바뀐 뒤에도 시작 스크립트가 이전 값을 계속 주입하는 문제를 피할 수 있습니다.

규칙, 프록시 모드 및 가짜 연결 성공 현상

요청이 Clash 로그에 들어왔다면 다음으로 규칙 적용 결과를 확인합니다. Rule 모드는 위에서부터 도메인, IP, GeoSite, GeoIP, 최종 규칙을 차례로 매칭합니다. 특정 도메인이 DIRECT에 매칭되면 선택한 프록시 노드를 거치지 않고 직접 연결됩니다. 특정 사이트를 점검할 때는 로그에서 적용된 정책 그룹을 확인한 뒤 구성 파일의 규칙 순서를 검토하세요.

Global 모드는 일반적으로 요청을 전역 정책 그룹으로 보내므로, 문제가 규칙에서 비롯되었는지 잠시 확인할 때 유용합니다. Rule 모드에서는 실패하지만 Global 모드에서는 성공한다면 로컬 포트와 노드는 대체로 정상이며, 규칙 설정을 다시 확인해야 합니다. Global 모드에 장기적으로 의존할 필요는 없습니다. Direct 모드는 요청을 직접 연결하므로 프록시 노드를 검증할 수 없습니다.

지연 시간 테스트 성공이 대상 요청 성공을 의미하지는 않습니다

지연 시간 테스트는 클라이언트에 미리 설정된 테스트 주소에만 접속하므로 모든 도메인에 접근할 수 있는지를 보장하지 않습니다.
노드에 수십 밀리초가 표시된다는 것은 당시 테스트 요청이 완료되었다는 뜻일 뿐, 브라우저가 해당 노드를 사용하고 있다는 의미는 아닙니다.
정책 그룹이 “자동 선택”으로 설정되어 있어도 실제 요청은 다른 정책 그룹에 매칭될 수 있습니다.
기존 브라우저 연결은 이전 채널을 재사용할 수 있으므로 노드를 바꾼 뒤에는 페이지를 새로고침하거나 앱을 다시 시작한 다음 테스트하세요.
UDP, IPv6, 일반 TCP 요청은 서로 다른 경로로 처리될 수 있으므로 한 가지 테스트만으로 전체 트래픽을 판단해서는 안 됩니다.

TUN 모드를 고려할 시점

시스템 프록시는 주로 HTTP, HTTPS 또는 SOCKS 프록시 설정을 능동적으로 읽는 프로그램에 적용됩니다. 일부 데스크톱 앱, 게임 런처, 시스템 구성 요소 및 자체 네트워크 스택을 구현한 소프트웨어는 시스템 프록시를 무시합니다. mihomo의 TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 가로채 이러한 앱을 처리할 수 있지만, 포트 입력 오류를 해결하는 대안은 아닙니다.

TUN을 켜기 전에 일반 프록시 테스트에서 구성, 노드, 규칙이 정상적으로 작동하는지 먼저 확인하세요. 그런 다음 클라이언트의 「설정」→「TUN 모드」에서 기능을 켭니다. Windows에서는 클라이언트가 네트워크 구성 요소를 설치하거나 활성화하도록 허용해야 할 수 있고, macOS에서는 네트워크 확장 권한을 확인해야 할 수 있습니다. 활성화한 뒤 로그를 다시 확인해 이전에 나타나지 않던 앱의 요청이 기록되는지 확인하세요.

정해진 순서로 최종 점검하기

현재 구성이 활성화되어 있고 정책 그룹에서 사용할 수 있는 노드를 선택했는지, Clash 또는 mihomo 코어가 실행 중인지 확인합니다.
「설정」→「포트 설정」에서 실제 포트를 확인하고, 경험에 의존해 반드시 7890일 것이라고 가정하지 마세요.
Test-NetConnection, lsof 또는 nc를 사용해 포트가 수신 중인지 확인합니다.
운영 체제의 프록시 주소가 127.0.0.1인지, 포트가 클라이언트의 포트와 일치하는지 확인합니다.
브라우저 프록시 확장의 영향을 제거하고 Firefox의 독립 설정과 시스템 우회 목록을 확인합니다.
curl의 --proxy 옵션으로 명시적 테스트를 진행하면서 Clash 로그를 함께 확인합니다.
브라우저는 작동하지만 터미널이 실패한다면 현재 세션에 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 설정합니다.
Git, npm 등 특정 도구 하나만 실패할 때는 해당 도구의 전용 프록시 설정을 확인하세요.
요청이 로그에 들어왔지만 실패한다면 Rule, Global, Direct 모드와 실제로 적용된 정책 그룹을 확인합니다.
앱이 시스템 프록시를 완전히 무시하고 일반 프록시 경로가 검증된 경우에만 TUN 모드를 켜세요.

효율적인 점검 과정에서는 브라우저에 로그가 생성되는지, 명시적 curl이 성공하는지, 일반 curl이 환경 변수를 읽는지, 대상 도메인에 어떤 규칙이 적용되는지를 비교 기록으로 남겨야 합니다. 문제를 “앱에서 로컬 포트까지”, “Clash의 규칙 처리”, “노드에서 대상 주소까지”의 세 구간으로 나누면 시스템 프록시를 켰는데도 작동하지 않는 원인을 대개 명확한 단계에서 찾을 수 있습니다.