Clash 시스템 프록시가 작동하지 않을 때: 브라우저·터미널 프록시 문제 해결

시스템 프록시, 규칙 모드, TUN부터 구분하기

클라이언트에서 ‘시스템 프록시’를 켜면 보통 운영체제의 HTTP·HTTPS 프록시 주소가 로컬에서 대기 중인 포트로 바뀝니다. 이 설정을 따르는지는 앱마다 다릅니다. 브라우저는 시스템 설정을 따를 수 있지만, 터미널의 curl·Git·패키지 관리자는 환경 변수나 별도 설정을 사용할 수 있습니다. 따라서 웹페이지는 열리는데 터미널 연결은 시간 초과되는 현상만으로 노드 장애라고 단정할 수 없습니다.

Clash 또는 mihomo 커널의 ‘규칙 모드’는 커널로 들어온 연결의 경로를 규칙에 따라 나눕니다. ‘전역 모드’에서는 보통 해당 연결을 전역 프록시 그룹으로 보냅니다. 어느 모드든 모든 프로세스가 자동으로 커널을 거치는 것은 아닙니다. TUN은 가상 네트워크 인터페이스와 라우팅으로 트래픽을 처리하는 별도의 진입 경로이며, 라우팅·DNS·프로세스 제외 설정·규칙의 영향을 받습니다.

증상	먼저 확인할 항목	판단 기준
브라우저와 터미널 모두 실패	커널, 수신 포트, 설정 활성화 여부	프록시를 명시한 curl로 로컬 포트에 연결되는지
브라우저는 정상, 터미널은 실패	환경 변수와 도구별 설정	같은 터미널에서 프록시를 명시하면 성공하는지
터미널은 정상, 브라우저는 실패	프록시 확장 프로그램, PAC, 예외 목록	브라우저 요청이 연결 패널에 표시되는지
요청은 커널에 들어오지만 직접 연결됨	일치한 규칙과 프록시 그룹 선택	연결 기록에 DIRECT가 표시되는지

기준선 확인: 로컬 포트와 프록시 지정 요청 점검

클라이언트의 실제 수신 포트 확인하기

클라이언트 설정에서 포트 또는 인바운드 설정 화면을 열고 HTTP·SOCKS·Mixed 포트와 현재 실행 중인 커널을 확인합니다. 클라이언트마다 메뉴 이름이 다르므로 실제 화면과 실행 설정을 기준으로 확인하세요. 아래에서는 127.0.0.1:7890을 Mixed 포트 예시로 사용합니다. 7890이 모든 클라이언트의 고정 포트인 것은 아닙니다. 컨트롤 인터페이스 포트를 프록시 포트와 혼동하지 마세요. external-controller는 관리 API를 제공합니다.

# 포트의 의미를 설명하기 위한 예시입니다. 전체 구독 설정을 덮어쓰지 마세요
mixed-port: 7890
allow-lan: false
mode: rule

Mixed 포트는 HTTP와 SOCKS 프록시 연결을 모두 받을 수 있습니다. 설정에 port: 7890만 있다면 HTTP 프록시로 사용하세요. socks-port: 7891만 있다면 해당 SOCKS 주소를 사용해야 합니다. 로컬에서만 접속한다면 문제 해결을 위해 LAN 접근을 켤 필요가 없습니다. 프록시 수신 포트를 공용 네트워크에 노출하지 마세요.

요청 한 번으로 진입 경로 문제와 외부 연결 문제 구분하기

macOS 또는 Linux 터미널에서 아래 curl 명령을 실행하세요. Windows PowerShell에서는 매개변수 해석에 영향을 주는 구버전 PowerShell의 별칭을 피하려면 curl 대신 curl.exe를 사용합니다. 테스트하는 동안 TUN을 잠시 끄고 클라이언트 하나만 실행해 여러 진입 경로가 섞이지 않도록 하세요.

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

Connection refused: 포트가 잘못됐거나 커널이 시작되지 않았거나 해당 주소에서 수신 대기 중이지 않을 때 주로 발생합니다.
로컬 포트 연결은 성공하지만 CONNECT가 실패하거나 502가 반환되면 클라이언트 로그, 노드 연결 상태, 해당 연결에 적용된 프록시 그룹을 확인하세요.
200 Connection established가 표시되면 HTTP 터널이 만들어졌다는 뜻일 뿐입니다. TLS 핸드셰이크와 대상 사이트의 응답도 확인해야 합니다.
대상 사이트의 HTTP 응답이 오면 이번 프록시 지정 요청이 정상 처리된 것입니다. 다른 앱의 설정까지 올바르다는 뜻은 아닙니다.

브라우저가 프록시를 사용하지 않을 때: 시스템 설정, 확장 프로그램, PAC 순으로 점검

시스템 설정이 실제로 적용됐는지 확인

Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동합니다. 클라이언트가 수동 프록시를 사용한다면 로컬 주소와 실제 포트가 표시되는지 확인하세요. 자동 구성 스크립트를 사용한다면 스크립트 주소가 여전히 유효한지 확인합니다. PAC 주소를 수동 프록시의 서버 주소에 입력하면 안 됩니다. 서로 다른 유형의 설정입니다.

macOS 14에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 사용 중인 네트워크 서비스 → ‘세부사항’ → ‘프록시’로 이동합니다. 연결되지 않은 이더넷 서비스가 아니라 Wi-Fi처럼 현재 활성화된 네트워크의 설정을 변경했는지 확인하세요. HTTP와 HTTPS 프록시 항목에는 보통 클라이언트의 HTTP 또는 Mixed 수신 포트를 입력합니다. 대상 URL이 HTTPS라고 해서 로컬 프록시 주소도 HTTPS여야 하는 것은 아닙니다.

Linux 데스크톱의 프록시 설정은 데스크톱 환경에 따라 다릅니다. GNOME에서는 ‘설정’ → ‘네트워크’ → ‘네트워크 프록시’에서 확인할 수 있습니다. 데스크톱 프록시 설정을 모든 샌드박스 앱, 백그라운드 서비스, 명령줄 도구가 따르는 것은 아니므로 뒤에서 터미널 설정도 따로 확인해야 합니다.

브라우저의 프록시 설정 출처를 하나만 남기기

Chrome에서는 chrome://extensions/, Edge에서는 edge://extensions/를 열고 프록시를 관리하는 확장 프로그램을 잠시 사용 중지한 다음 브라우저를 완전히 종료했다가 다시 실행하세요.
Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’으로 이동해 ‘프록시 사용 안 함’, ‘시스템 프록시 설정 사용’, 수동 설정 중 무엇이 선택됐는지 확인하세요. 문제 해결 중에는 우선 시스템 설정과 일치시키세요.
조직에서 관리하는 브라우저라면 chrome://policy/ 또는 edge://policy/도 확인하세요. 정책으로 프록시가 강제 설정되어 있으면 클라이언트에서 시스템 설정을 바꿔도 브라우저 동작이 달라지지 않을 수 있습니다.
같은 테스트 URL에 다시 접속하면서 클라이언트의 연결 패널을 열고 대상 도메인, 일치한 규칙, 프록시 경로, 트래픽이 표시되는지 확인하세요.

시크릿 창은 프록시를 확실히 분리해 테스트할 수 있는 환경이 아닙니다. 일부 확장 프로그램은 시크릿 모드에서도 실행되도록 허용할 수 있고 시스템 프록시 설정도 그대로 적용됩니다. 필요하면 임시 브라우저 프로필로 비교하세요. 평소 사용하는 프로필 설정을 바로 지우지는 마세요.

PAC와 프록시 예외 목록 확인

PAC 스크립트는 도메인별로 프록시 주소나 DIRECT를 반환할 수 있습니다. 특정 도메인을 직접 연결하도록 설정되어 있으면 요청이 커널을 거치지 않으므로 Clash의 라우팅 규칙을 바꿔도 해당 요청에는 영향을 주지 않습니다. 먼저 기존 설정을 저장한 뒤 수동 프록시를 명시적으로 지정해 비교해 보세요. 출처가 불분명한 PAC와 프록시 확장 프로그램을 여러 개 겹쳐 사용하지 마세요.

시스템과 브라우저의 예외 목록도 프록시를 우회하게 합니다. 테스트 도메인, 와일드카드 도메인, 로컬 네트워크 주소, ‘로컬 주소에는 프록시 사용 안 함’ 옵션을 중점적으로 확인하세요. localhost 접속으로는 공용 인터넷 프록시가 작동하는지 확인할 수 없습니다. 루프백 주소는 보통 별도 우회 처리가 적용됩니다.

Windows 터미널: PowerShell과 CMD 설정

PowerShell, CMD, 앱에 내장된 터미널이 같은 프록시 설정을 사용하는 것은 아닙니다. 아래 환경 변수는 현재 프로세스와 이후에 시작되는 하위 프로세스에만 적용됩니다. 이미 실행 중인 터미널, 편집기, 백그라운드 작업에는 자동으로 반영되지 않습니다. 먼저 임시 설정으로 확인한 뒤 정상 작동하면 영구 저장을 고려하세요.

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 -I --connect-timeout 10 --max-time 20 https://example.com/

# 현재 프록시 관련 환경 변수 확인
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# 테스트가 끝나면 이번에 설정한 값 삭제
Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue

CMD 현재 창

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"
curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/

rem 테스트가 끝나면 설정 삭제
set "http_proxy="
set "https_proxy="
set "no_proxy="

https_proxy는 HTTPS 요청에 사용할 프록시를 지정하는 변수이지, 프록시 연결 자체에 TLS를 사용하라는 뜻은 아닙니다. 이 예시에서는 로컬 HTTP 프록시의 CONNECT 메서드로 터널을 만들므로 값은 http://127.0.0.1:7890입니다.

macOS와 Linux: 환경 변수, SOCKS, 영구 설정

현재 셸에서 먼저 테스트하기

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 -I --connect-timeout 10 --max-time 20 https://example.com/

# 대소문자 형식을 모두 확인해 이전 설정의 영향을 배제
env | grep -i proxy

# 이번에 설정한 값 삭제
unset http_proxy https_proxy no_proxy

환경 변수 이름의 대소문자 지원 여부는 프로그램마다 다릅니다. curl은 HTTP 프록시에 소문자 http_proxy를 사용하므로 대문자 HTTP_PROXY만 설정한 뒤 프록시가 작동하지 않는다고 판단하지 마세요. 이전 설정에 ALL_PROXY, HTTPS_PROXY 또는 대소문자만 다른 변수가 있다면 먼저 기존 값을 기록한 뒤 충돌하는 항목을 삭제하세요. no_proxy의 도메인 일치 방식도 도구마다 다르므로 복잡한 목록을 여러 도구에 그대로 복사하지 않는 편이 좋습니다.

프록시 측에서 도메인을 조회하는지 SOCKS로 테스트하기

# 7890이 실제 Mixed 또는 SOCKS 포트인 경우에만 사용
curl -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

curl에서 socks5h://를 사용하면 대상 호스트 이름을 프록시 쪽에서 조회하고, socks5://는 기본적으로 로컬에서 조회합니다. 이 차이를 활용해 로컬 DNS 문제를 확인할 수 있지만 모든 프로그램이 같은 URL 형식을 지원하는 것은 아닙니다. SOCKS 환경 변수를 지원하지 않는 도구에서는 해당 도구가 명시적으로 지원하는 HTTP 프록시 설정을 사용하세요.

테스트에 성공하면 사용하는 셸에 맞춰 필요한 export 행을 ~/.zshrc 또는 ~/.bashrc에 추가한 뒤 새 터미널에서 확인하세요. 로그인 셸, 데스크톱에서 실행한 앱, systemd 서비스는 환경 변수를 불러오는 방식이 다르므로 파일 하나를 수정하면 모든 프로세스에 적용된다고 가정하면 안 됩니다. sudo로 실행하는 명령에서는 환경 변수가 제거될 수도 있습니다.

WSL, 컨테이너, 가상 머신 안의 127.0.0.1은 대개 각자의 네트워크 환경을 가리키므로 호스트를 의미하지 않을 수 있습니다. WSL 네트워크 모드에 따라 루프백 주소에 접근할 수 있는지도 달라집니다. 연결에 실패하면 먼저 호스트 주소와 접근 가능한 포트를 확인하세요. 환경 간 연결이 필요하다면 신뢰할 수 있는 네트워크에서 필요한 수신 포트만 열고 방화벽을 설정하세요. 모든 네트워크에 무작정 노출하지 마세요.

명령이 계속 실패할 때: 도구 설정, 규칙, DNS 확인

Git 등 도구별 설정이 환경 변수를 덮어쓸 수 있음

Git의 전역 설정, 저장소 설정, URL별 프록시 설정에 따라 결과가 달라질 수 있습니다. 먼저 설정이 어디에서 왔는지 확인한 다음, 한 번만 적용되는 명령으로 테스트하세요. 설정을 바꾸고 복구를 잊지 않도록 주의해야 합니다. 아래 테스트는 공개 저장소를 사용하므로 명령에 계정이나 비밀번호를 넣을 필요가 없습니다.

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

패키지 관리자, IDE, 다운로드 도구에도 별도 설정이 있을 수 있습니다. 브라우저 연결 성공은 브라우저 경로가 작동한다는 뜻일 뿐, 각 도구의 연결 테스트를 대신하지 않습니다. 로그를 공유할 때는 구독 URL, 액세스 토큰, 계정 정보, 인증 정보가 포함된 프록시 주소를 가리세요.

커널에 들어온 뒤 규칙 확인하기

연결 패널에 대상 요청이 표시되면 최종 프록시 경로를 확인하세요. DIRECT로 표시되면 적용된 규칙과 프록시 그룹이 현재 직접 연결을 선택했는지 확인합니다. 특정 노드가 표시되면 해당 노드에서 대상 사이트까지 연결되는지 확인하세요. 구독을 가져오는 데 성공했어도 설정이 활성화됐거나 각 프록시 그룹에서 사용 가능한 노드를 선택했다는 뜻은 아닙니다.

잠시 전역 모드로 바꾸고 연결을 확인한 노드를 선택해 비교할 수 있습니다. 전역 모드는 작동하지만 규칙 모드에서 실패한다면 규칙 매칭과 그룹 선택을 먼저 확인하세요. 테스트가 끝나면 원래 모드로 되돌립니다. 전역 모드도 커널에 들어온 연결만 처리하므로 브라우저가 프록시 설정을 읽지 않거나 터미널에 진입 경로가 설정되지 않은 문제는 해결하지 못합니다.

오류가 도메인 조회를 명확히 가리킨다면 앱, 로컬 시스템, HTTP 프록시, SOCKS 프록시 중 어디에서 이름을 조회하는지 먼저 구분하세요. 브라우저의 보안 DNS 설정은 조회 경로를 바꿀 수 있지만, 브라우저 프록시 문제의 원인이 항상 DNS인 것은 아닙니다. 처음부터 DNS 설정을 초기화하거나 Fake-IP 범위를 변경하면 여러 변수가 동시에 바뀔 수 있으니 피하세요.

TUN을 사용할 상황과 재검증 방법

프록시를 명시적으로 설정할 수 없는 앱이라면 해당 기능을 지원하는 mihomo 클라이언트에서 TUN 사용을 고려할 수 있습니다. 켜기 전에 클라이언트 버전과 커널 지원 여부, 권한 요구 사항, 기존 VPN 라우팅을 확인하세요. TUN은 관리자 권한이 필요할 수 있고 다른 가상 네트워크 인터페이스, 라우팅, DNS 처리와 충돌할 수 있습니다. 포트를 확인하기 전에 무조건 시도하는 해결책은 아닙니다.

먼저 TUN을 끈 상태에서 로컬 프록시를 명시한 요청을 성공시켜 노드와 수신 경로가 정상인지 확인합니다.
브라우저 시스템 프록시 설정을 복구한 뒤 브라우저만 따로 테스트하고, 클라이언트 연결 기록에 도메인과 적용 규칙이 표시되는지 확인합니다.
새 터미널 세션에서 프록시 환경 변수를 테스트하고 도구별 설정과 예외 목록을 확인합니다.
프록시를 지원하지 않는 앱이 실제로 있을 때 TUN을 켜고 기본 경로, DNS, 앱 연결의 변화를 관찰합니다.
클라이언트를 종료한 뒤 네트워크가 복구됐는지 확인하세요. 중지된 로컬 포트를 계속 가리킨다면 남아 있는 시스템 프록시 설정을 끄거나 현재 세션의 변수를 삭제하세요.

문제 해결 기록에는 운영체제 및 클라이언트·커널 버전, 수신 포트, 테스트 명령, 원문 오류, 연결 패널의 규칙 매칭 결과를 남기세요. ‘앱 진입 경로 → 로컬 수신 포트 → 규칙과 프록시 그룹 → 노드 출구 → 대상 사이트’ 순서로 하나씩 확인하면 클라이언트를 반복해서 재설치하는 것보다 원인을 찾기 쉽습니다. 기본 사용법은 빠른 시작, 설정 항목 설명은 프로토콜 참고, 자주 묻는 질문은 도움말 센터에서 확인하세요.