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

먼저 프록시 포트를 확인한 뒤 앱 설정을 점검하세요

현재 설정은 그대로 둔 채, 프록시를 명시한 요청을 한 번 보내 로컬 포트부터 확인하세요. 시스템 프록시를 켜면 클라이언트가 프록시 주소를 운영체제 설정에 기록하려고 하지만, 커널이 실제로 포트를 열어 두고 있다는 뜻은 아닙니다. 모든 앱이 해당 설정을 읽는다는 보장도 없습니다. 브라우저, 명령줄 도구, 가상 네트워크 어댑터는 서로 다른 경로이므로 한꺼번에 점검하면 정상적인 직접 연결 규칙을 프록시 오류로 오해하기 쉽습니다.

먼저 세 가지 기본 항목을 확인하세요

클라이언트 커널이 실행 중이고 현재 설정이 활성화되어 있는지 확인하세요. 구독을 가져오기만 하고 해당 설정으로 전환하지 않았다면 규칙이 로드된 것이 아닙니다.
현재 HTTP 또는 mixed 포트, 실행 모드, 선택된 정책 그룹의 노드를 기록하세요. 점검하는 동안에는 트래픽 경로가 겹치지 않도록 TUN을 잠시 끄세요.
클라이언트의 ‘연결’과 ‘로그’ 화면을 열고 같은 대상으로 요청을 보내세요. 스위치 색상만 보지 말고 대상 도메인, 적용된 규칙, 최종 정책을 확인하세요.

클라이언트마다 메뉴 이름은 다릅니다. 설정 파일에서 port는 HTTP 프록시 포트, socks-port는 SOCKS 포트, mixed-port는 HTTP와 SOCKS 요청을 모두 받는 포트를 뜻합니다. 클라이언트가 값을 덮어쓸 수 있으므로 구독 원문이 아니라 최종 실행 설정을 확인하세요. 로컬 기기에서만 사용할 경우 점검을 위해 ‘LAN에서 연결 허용’을 켤 필요는 없습니다.

curl로 프록시를 지정해 포트 문제와 규칙에 따른 직접 연결을 구분하세요

Windows PowerShell에서는 curl.exe를 사용하세요. Windows PowerShell 5.1에서 curl은 Invoke-WebRequest 별칭으로 실행될 수 있습니다. macOS와 Linux에서는 curl을 그대로 사용하면 됩니다. 아래 명령의 example.com은 요청 경로 확인용이며, 지역 제한 해제 여부나 노드 속도를 판단하기 위한 주소가 아닙니다.

Windows: HTTP 프록시를 명시해 요청하기

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

macOS / Linux: 같은 대상으로 다시 테스트하기

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

--noproxy ""는 이번 요청에서 우회 목록을 비워 기존 NO_PROXY의 영향을 차단합니다. 상세 출력에는 먼저 127.0.0.1:7890에 연결한 뒤 HTTPS 대상에 CONNECT example.com:443을 요청하는 과정이 표시되어야 합니다. 터널이 만들어졌다면 요청이 로컬 프록시에 도달한 것입니다. 다만 최종적으로 프록시 노드를 거쳤는지 DIRECT로 연결됐는지는 클라이언트 연결 기록도 함께 확인해야 합니다.

확인된 결과	가능성이 높은 원인	다음 단계
로컬 연결이 거부됨	포트가 열려 있지 않거나 포트 번호가 잘못됨	커널 상태, 최종 포트, 포트 점유 여부를 확인하세요
터널은 만들어졌지만 요청 시간이 초과됨	프록시 포트는 작동하지만 이후 연결에 문제가 있음	선택한 노드, 대상 서버 연결 상태, 커널 로그를 확인하세요
클라이언트 기록에 DIRECT로 표시됨	요청은 커널에 도달했지만 규칙에 따라 직접 연결됨	적용된 도메인 규칙과 정책 그룹을 확인하세요
프록시를 명시한 요청은 성공하지만 브라우저는 실패함	브라우저의 프록시 설정이 다를 수 있음	확장 프로그램, PAC, 브라우저 자체 설정을 확인하세요

Windows에서는 Get-NetTCPConnection -LocalPort 7890 -State Listen을 실행해 포트를 수신 대기 중인 프로세스를 확인할 수 있습니다. Linux에서는 ss -ltnp 'sport = :7890', macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을 실행하세요. 다른 프로그램이 포트를 사용 중이라면 먼저 충돌을 해결하세요. 구독을 반복해서 업데이트할 필요는 없습니다.

브라우저만 문제일 때: 확장 프로그램, 시스템 프록시, PAC 점검

프록시를 명시한 테스트가 성공하면 브라우저를 점검하세요. Chrome과 Edge는 대체로 시스템 프록시를 사용하지만, 확장 프로그램이나 시작 매개변수, 조직 정책이 설정을 덮어쓸 수 있습니다. Firefox에는 별도의 연결 설정도 있습니다. 브라우저에서 웹페이지가 열린다고 프록시를 사용 중인 것은 아닙니다. 캐시된 페이지나 규칙에 따른 직접 연결일 수 있습니다.

먼저 운영체제에 적용된 프록시 설정을 확인하세요

Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’로 이동해 ‘수동 프록시 설정’의 주소와 포트를 확인하세요. 로컬 HTTP 포트를 사용한다면 주소는 127.0.0.1이며 포트는 클라이언트 설정과 같아야 합니다.
macOS 13 이상: ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘프록시’로 이동하세요. 웹 프록시, 보안 웹 프록시, 자동 프록시 구성 설정을 확인하고 실제로 사용 중인 네트워크 서비스를 수정하고 있는지 확인하세요.
Firefox: ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’으로 이동해 ‘시스템 프록시 설정 사용’을 선택했는지 확인하세요. 수동 프록시를 사용한다면 주소와 포트, 프록시를 사용하지 않을 주소 목록을 기록하세요.

Windows의 netsh winhttp show proxy는 WinHTTP 설정을 보여 줍니다. 브라우저가 사용하는 사용자 프록시 설정을 직접 나타내지는 않습니다. 이 명령에 직접 연결로 표시된다고 해서 클라이언트가 시스템 프록시를 설정하지 않았다고 단정하지 마세요. 브라우저 문제를 해결하려고 컴퓨터 전체의 WinHTTP 설정부터 바꾸는 것도 피하세요.

프록시를 제어하는 확장 프로그램을 잠시 사용 중지하세요

Chrome에서는 chrome://extensions/, Edge에서는 edge://extensions/를 열어 프록시를 제어할 수 있는 확장 프로그램을 잠시 사용 중지한 뒤 브라우저를 완전히 종료하고 다시 실행하세요. 시크릿 창으로는 프록시 설정의 출처가 분리되지 않을 수 있고, 모든 확장 프로그램이 사용 중지되는 것도 아닙니다. 조직에서 관리하는 기기라면 chrome://policy/ 또는 edge://policy/도 확인하세요. 정책으로 제어되는 설정은 관리자에게 확인해야 합니다.

PAC가 DIRECT를 반환하면 로컬 커널은 해당 요청을 받지 않습니다

PAC는 브라우저에서 프록시를 선택하는 스크립트이며 Clash 커널의 규칙과는 별개의 계층입니다. PAC가 DIRECT를 반환하면 브라우저는 직접 연결합니다. PROXY 127.0.0.1:7890을 반환해야 요청이 로컬 HTTP 포트로 전달됩니다. PAC에 PROXY 127.0.0.1:7890; DIRECT가 있으면 프록시를 사용할 수 없을 때 직접 연결로 전환될 수도 있습니다.

점검할 때는 자동 구성 스크립트를 잠시 끄고 수동 프록시 설정 하나만 사용한 뒤 브라우저를 다시 시작해 같은 대상으로 요청하세요. 복원할 수 있도록 기존 PAC 주소를 기록해 두세요. 두 설정을 동시에 켜 놓고 어느 쪽이 우선인지 추측하지 마세요. 브라우저 요청은 클라이언트에 전혀 기록되지 않지만 curl 요청은 기록된다면 규칙 모음보다 브라우저의 우회 목록과 PAC를 먼저 확인하세요.

터미널만 문제일 때: 환경 변수와 도구별 설정 점검

터미널 프로그램은 시스템 프록시를 사용하지 않을 수 있습니다. curl, Git, 패키지 관리자는 각자 설정을 읽으므로 시스템 프록시를 켰는데도 직접 연결되는 일이 흔합니다. 현재 터미널의 환경 변수를 확인한 다음 도구별 설정을 점검하세요. 이미 실행 중인 프로세스에는 나중에 바꾼 환경 변수가 자동으로 적용되지 않는 경우가 많습니다.

macOS / Linux: 명령 하나에만 프록시 설정하기

env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 \
curl -v --noproxy "" --max-time 20 https://example.com/ -o /dev/null

여기서 https_proxy 값이 http://로 시작하는 것은 로컬 HTTP 프록시에 연결한 뒤 CONNECT로 HTTPS 사이트까지 터널을 만든다는 뜻입니다. 대상 URL이 HTTPS라고 해서 로컬 프록시 주소를 https://127.0.0.1:7890으로 바꾸지 마세요. 일반 HTTP 프록시 포트는 TLS 프록시 연결을 지원하지 않습니다.

curl은 HTTP 프록시 환경 변수로 소문자 http_proxy를 사용합니다. 다른 변수의 대소문자 지원 여부는 도구마다 다릅니다. NO_PROXY 또는 no_proxy에 대상 도메인이나 주소 범위, *가 포함되어 있으면 요청이 프록시를 건너뛸 수 있습니다. 필요한 로컬 우회 항목은 유지하고 하나씩 확인하세요. 우회 규칙을 모두 지운 채 계속 사용하는 것은 피해야 합니다.

PowerShell: 현재 세션에 프록시 환경 변수 설정하기

Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

$env:HTTP_PROXY = 'http://127.0.0.1:7890'
$env:HTTPS_PROXY = 'http://127.0.0.1:7890'
curl.exe -v --noproxy "" --max-time 20 https://example.com/ -o NUL

위 설정은 현재 PowerShell 세션과 이후에 실행하는 자식 프로세스에만 적용됩니다. 이미 실행 중인 IDE, 터미널 탭, 백그라운드 작업의 환경 변수는 바뀌지 않습니다. 테스트를 취소할 때는 변수가 원래 없었다면 아래 명령을 사용하세요. 기존 값이 있었다면 기록해 둔 값으로 복원해야 합니다.

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY -ErrorAction SilentlyContinue

Git 연결 문제는 Git 자체의 프록시 설정을 확인하세요

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

이 명령은 저장소, 현재 사용자 또는 시스템 설정에서 프록시 관련 항목을 표시합니다. 특정 URL에만 적용되는 설정이 있을 수도 있습니다. 일치하는 항목이 없으면 명령이 0이 아닌 상태 코드로 종료될 수 있지만, Git이 손상된 것은 아닙니다. HTTPS 저장소와 SSH 저장소는 전송 방식이 다르므로 http.proxy로 SSH 연결 문제를 해결할 수 없습니다. npm, pip 같은 도구도 각각 설정을 확인해야 합니다. curl이 성공한다고 모든 개발 도구가 프록시를 사용한다고 볼 수는 없습니다.

규칙과 DNS 점검: 커널에 도달했다고 노드를 거치는 것은 아닙니다

브라우저나 터미널 요청이 연결 목록에 나타난다면 ‘프록시 진입 문제’에서 ‘라우팅 문제’로 점검 방향을 바꾸세요. 규칙 모드에서는 규칙을 순서대로 적용한 뒤 지정된 정책이나 정책 그룹으로 요청을 보냅니다. DIRECT 규칙에 걸리거나 직접 연결 구성원을 선택했거나 프로세스 규칙이 먼저 적용되면 로컬 네트워크로 연결될 수 있습니다.

방금 테스트한 대상을 찾아 적용된 규칙, 정책 경로, 선택된 노드를 기록하세요. 정책 그룹 이름만 확인해서는 부족합니다.
실행 모드가 직접 연결 모드가 아닌지 확인하세요. 규칙 모드라면 규칙 순서를 살펴보고 특히 앞쪽에 있는 도메인, 프로세스, 주소 규칙을 확인하세요.
필요하다면 잠시 전역 모드로 전환하고 전역 정책에서 사용 가능한 프록시 노드를 선택하세요. 같은 요청을 다시 보낸 뒤 원래 모드로 복원하세요. 전역 모드 테스트는 규칙의 영향을 분리하기 위한 것이며 영구적인 해결책은 아닙니다.
요청이 커널에 도달한 뒤 DNS 조회 실패가 표시된다면 DNS 설정과 로그를 확인하세요. 노드, DNS, 규칙 모음을 한꺼번에 바꾸지 마세요.

브라우저의 보안 DNS 설정은 도메인 조회 경로에 영향을 줄 수 있지만, 이것만으로 HTTP 프록시를 우회한다고 단정할 수는 없습니다. HTTP CONNECT를 사용하면 브라우저가 대상 도메인을 프록시에 전달할 수 있습니다. TUN에서는 DNS 가로채기와 도메인 매핑도 관련됩니다. DNS 설정만 보고 판단하지 말고 연결 기록으로 요청 경로를 확인하세요. Fake-IP 설정을 바꾼 뒤에는 연결을 새로 만들어야 할 수 있으므로 기존 장시간 연결로 변경 결과를 판단하지 마세요.

TUN을 켜야 할 때: 프록시 설정을 읽지 않는 앱 처리

프록시를 명시한 요청, 브라우저의 시스템 프록시, 터미널 환경 변수가 모두 정상인데 프록시 설정을 읽지 않는 일부 앱만 직접 연결된다면 TUN 사용을 고려하세요. TUN은 가상 네트워크 어댑터와 라우팅으로 지정된 트래픽을 처리하며 시스템 프록시와는 별개의 설정입니다. 사용할 수 없는 노드나 잘못된 구독, 직접 연결 규칙을 우회하는 해결책은 아닙니다.

권한, 라우팅, DNS 순서로 확인하세요

권한과 서비스: 클라이언트 안내에 따라 필요한 서비스를 설치하거나 실행하고 가상 네트워크 어댑터가 정상적으로 만들어졌는지 확인하세요. Windows, macOS, Linux의 권한 방식은 서로 다르므로 같은 절차를 일괄 적용하면 안 됩니다.
라우팅 처리: 현재 실행 설정의 tun.enable, auto-route 항목과 로그를 확인하세요. TUN 네트워크 어댑터가 있어도 모든 대상 주소나 프로토콜이 해당 어댑터로 전달된다는 뜻은 아닙니다.
DNS와 충돌: 다른 VPN, 가상 머신 네트워크, 기업용 보안 소프트웨어가 라우팅이나 DNS를 동시에 바꾸는지 확인하세요. 한 번에 한 가지 원인만 비활성화하고 복구 방법을 기록해 정상적인 업무 네트워크에 문제가 생기지 않도록 하세요.

데스크톱 클라이언트는 TUN 설정 일부를 대신 관리할 수 있지만, mihomo 커널만 직접 실행하는 환경에서는 권한과 실행 설정을 직접 확인해야 합니다. LAN 기기에 접속할 수 없거나 DNS 시간이 초과되거나 TUN을 켠 뒤 인터넷이 모두 끊기면, 먼저 TUN을 끄고 정상 작동을 확인한 시스템 프록시 경로를 복원한 다음 라우팅과 DNS를 점검하세요. 모든 문제를 ‘관리자 권한으로 실행해야 한다’고 단정하지 마세요.

테스트 결과를 바탕으로 원인을 좁히고 재설치를 반복하지 마세요

효율적인 점검 기록에는 네 가지가 포함됩니다. 로컬 프록시 포트에 연결할 수 있는지, 요청이 커널에 표시되는지, 어떤 정책이 적용되는지, 어느 앱에서 실패하는지 기록하세요. 같은 대상을 curl로 프록시를 명시해 요청하고 브라우저와 앱에서도 각각 테스트하면 사이트, 캐시, 노드 상태 차이로 생기는 혼선을 줄일 수 있습니다.

프록시를 명시한 curl도 실패함: 포트, 커널 실행 상태, 이후 노드 연결부터 해결하세요.
프록시를 명시한 curl은 성공하지만 브라우저 연결 기록이 없음: 확장 프로그램, PAC, 브라우저의 프록시 설정 출처를 먼저 확인하세요.
브라우저는 성공하지만 터미널은 실패함: 현재 프로세스의 환경 변수, 우회 목록, 도구별 설정을 확인하세요.
요청은 모두 기록되지만 직접 연결됨: 규칙과 정책 선택을 확인하세요. 시스템 프록시 설정을 더 바꿀 필요는 없습니다.
특정 앱만 직접 연결됨: 앱이 프록시를 지원하는지 확인한 뒤 앱별 설정과 TUN 중 적절한 방법을 선택하세요.

다른 사람에게 점검을 요청할 때는 운영체제 버전, 클라이언트와 커널 버전, 실제 수신 포트, 민감 정보를 가린 오류 로그를 함께 전달하세요. 구독 주소, 액세스 토큰, 노드 비밀번호, 개인 도메인은 삭제해야 합니다. 원인을 찾지 못했다면 문제 해결 안내를 참고하세요. 프록시 설정을 복구한 뒤에는 사용 가이드에 따라 평소 설정을 정리할 수 있습니다.