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

먼저 구분할 것: 클라이언트에 요청이 들어오지 않는지, 들어온 뒤 아웃바운드 연결이 실패하는지

‘시스템 프록시 사용’이 켜져 있다는 것은 클라이언트가 운영체제의 프록시 설정을 변경하려 했다는 뜻일 뿐, 모든 앱이 해당 설정을 읽는다는 의미는 아닙니다. 브라우저는 확장 프로그램이 프록시를 제어할 수 있고, 터미널 도구는 환경 변수만 읽을 수 있습니다. 요청이 Clash에 들어왔더라도 규칙에 따라 DIRECT로 연결되거나 노드 연결에 실패해 요청이 완료되지 않을 수 있습니다.

이 글은 Windows, macOS, Linux 데스크톱 환경을 중심으로 설명합니다. Clash는 프록시 코어와 관련 클라이언트 생태계를 가리키는 통칭이며, Clash Meta는 이후 mihomo라는 이름을 사용합니다. 설정 메뉴 위치는 클라이언트마다 다르므로 코어 이름만으로 인터페이스의 메뉴를 알 수는 없습니다. Android와 iOS는 VPN으로 트래픽을 처리하므로 데스크톱의 시스템 프록시와 경로가 다릅니다. 이 글의 시스템 설정 절차를 그대로 적용하지 마세요.

1. 클라이언트에서 설정이 로드되었는지 확인하고, 아웃바운드 모드는 우선 ‘규칙’으로 설정한 뒤 정책 그룹에서 선택된 노드를 기록합니다.
2. 클라이언트의 ‘연결’ 페이지를 열고 ‘로그’도 확인합니다. 필요하면 로그 수준을 잠시 info로 설정하세요.
3. 대상 도메인을 하나 정해 새 요청을 보낸 다음 연결 시각, 대상 주소, 적용된 규칙, 아웃바운드 경로를 확인합니다.
4. 기록이 없다면 먼저 앱의 프록시 진입 경로를 확인하세요. 기록이 있고 DIRECT로 연결됐다면 규칙을, 기록은 있지만 연결 시간이 초과됐다면 노드, DNS, 원격 서버를 점검하세요.

로컬 프록시 진입점: 주소, 포트, 코어 상태 확인

아래 예시에서는 127.0.0.1:7890을 사용합니다. 7890은 흔히 쓰이는 설정값일 뿐 모든 클라이언트의 고정 포트는 아닙니다. 먼저 클라이언트 ‘설정’의 ‘포트’ 또는 ‘혼합 포트’ 항목에서 실제 값을 확인한 뒤 명령어의 포트를 바꾸세요. 컨트롤러 포트나 대시보드 주소를 프록시 포트로 잘못 입력하지 않도록 주의하세요.

Windows: 포트 수신 상태와 프로세스 확인

netstat -ano | findstr :7890

출력에서 로컬 주소가 127.0.0.1:7890 또는 해당 수신 주소이고 상태가 LISTENING인 행을 찾으세요. 마지막 열의 PID를 적어 둔 다음 ‘작업 관리자’ → ‘세부 정보’에서 프로세스를 확인합니다. 다른 클라이언트가 포트를 점유하고 있으면 현재 클라이언트의 인터페이스는 정상적으로 시작되어도 코어가 포트를 열지 못할 수 있습니다.

macOS, Linux: TCP 수신 상태 확인

lsof -nP -iTCP:7890 -sTCP:LISTEN

시스템에 lsof가 설치되어 있지 않다면 Linux에서는 ss -lntp로 수신 목록을 확인할 수 있습니다. 수신 중인 포트가 없다면 브라우저 설정을 바꾸기 전에 코어 시작 로그, 설정 구문 오류, 포트 충돌부터 확인하세요. 로컬에서만 사용할 경우 보통 ‘LAN 연결 허용’을 켤 필요가 없으며 수신 주소를 모든 네트워크 인터페이스로 확대할 필요도 없습니다.

브라우저 점검: 시스템 설정, 확장 프로그램, PAC, 예외 목록

운영체제에 실제로 저장된 프록시 주소 확인

• Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 엽니다. ‘수동 프록시 설정’의 서버와 포트를 확인하고 ‘설정 스크립트 사용’이 이전 PAC 주소를 가리키고 있지 않은지도 살펴보세요.
• macOS 13 이상: ‘시스템 설정’ → ‘네트워크’ → 현재 사용 중인 네트워크 서비스 → ‘세부사항’ → ‘프록시’를 엽니다. ‘웹 프록시(HTTP)’, ‘보안 웹 프록시(HTTPS)’, ‘자동 프록시 구성’을 확인하세요. Wi-Fi나 유선 네트워크를 전환했다면 해당 서비스의 설정도 다시 확인해야 합니다.
• GNOME 데스크톱: 일반적으로 ‘설정’ → ‘네트워크’ → ‘네트워크 프록시’에서 확인할 수 있습니다. 데스크톱 환경마다 시스템 프록시 설정 방식이 다르며, 앱이 모두 같은 설정을 읽는 것도 아닙니다.

HTTP 프록시 주소에는 보통 127.0.0.1을 입력하고 포트는 별도 항목에 7890을 입력합니다. HTTPS 웹사이트도 HTTP 프록시의 CONNECT 터널을 통해 접속하므로 프록시 서버 주소에 반드시 https://를 붙여야 하는 것은 아닙니다. 입력란에 프로토콜 접두사가 필요한지는 시스템 인터페이스의 안내를 따르세요.

Chrome, Edge: 확장 프로그램과 정책이 설정을 덮어쓰는지 확인

Chrome 주소창에서 chrome://settings/system, Edge에서는 edge://settings/system을 열어 시스템 프록시 설정으로 이동합니다. 이어서 chrome://extensions 또는 edge://extensions에서 프록시 전환 확장 프로그램을 잠시 사용 중지하고 브라우저를 완전히 종료한 뒤 다시 실행하세요.

시크릿 창만으로는 충분한 격리 테스트가 되지 않습니다. 일부 확장 프로그램은 시크릿 모드에서도 허용될 수 있으며 시스템 프록시와 조직 정책도 계속 적용됩니다. 관리되는 기기라면 chrome://policy 또는 edge://policy도 확인하세요. 조직 정책으로 프록시가 고정되어 있다면 설정을 계속 덮어쓰지 말고 관리자에게 문의하세요.

Firefox: 별도의 네트워크 설정 확인

Firefox에서 ‘설정’ → ‘일반’ → 페이지 아래쪽의 ‘네트워크 설정’ → ‘설정’을 엽니다. 시스템 설정을 따르려면 ‘시스템 프록시 설정 사용’을 선택하세요. ‘수동 프록시 설정’을 선택했다면 HTTP 프록시와 포트, HTTPS에도 같은 프록시를 사용할지 확인합니다. ‘프록시 사용 안 함’과 ‘이 네트워크의 프록시 설정 자동 감지’는 클라이언트가 설정한 수동 프록시를 읽는 것과 다릅니다.

PAC 및 우회 목록: 도메인별 분기가 클라이언트에 도달하기 전에 적용될 수 있습니다

PAC 스크립트는 URL에 따라 DIRECT 또는 프록시 주소를 반환할 수 있습니다. PAC가 대상 도메인에 DIRECT를 반환하면 요청은 Clash에 들어오지 않으므로 로컬 규칙도 적용되지 않습니다. 점검할 때는 기존 설정을 기록하고 자동 스크립트를 끈 뒤 수동 HTTP 프록시만 사용하는 등 프록시 진입점을 하나만 남겨 동일한 대상에 다시 요청하세요.

Windows의 프록시 예외, macOS의 ‘다음 호스트 및 도메인에 프록시 설정 사용 안 함’, Firefox의 ‘프록시 사용 안 함’ 목록도 확인하세요. localhost, 127.0.0.1, 내부 도메인은 우회 대상으로 지정되는 경우가 많습니다. 따라서 로컬 페이지 접속으로 외부 트래픽이 프록시를 거치는지 판단할 수 없습니다. 테스트할 때는 새 요청을 보내고 클라이언트에 해당 도메인의 연결 기록이 나타나는지 확인해 브라우저 캐시의 영향을 피하세요.

터미널 점검: 프록시를 명시해 요청한 뒤 환경 변수 확인

터미널은 브라우저가 아니라 프로세스가 실행되는 환경입니다. curl, Git, 패키지 관리자, 스크립트 런타임마다 프록시 설정을 읽는 방식이 다릅니다. 데스크톱 시스템에서 프록시를 켜도 이 도구들이 자동으로 프록시를 사용한다고 보장할 수 없습니다. 먼저 요청 하나에 로컬 프록시 주소를 명시하면 환경 변수와 앱 설정으로 인한 변수를 대부분 배제할 수 있습니다.

curl로 최소 테스트하기

macOS 또는 Linux에서 아래 명령어를 실행하세요. Windows PowerShell에서도 같은 매개변수를 사용하되 명령어 이름은 curl.exe로 입력하세요. Windows PowerShell 5.1에서는 curl 별칭이 다른 명령을 가리킬 수 있습니다.

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

--noproxy ""는 이번 요청의 우회 목록을 비웁니다. --connect-timeout 10과 --max-time 20은 각각 연결 단계와 요청 전체의 제한 시간을 초 단위로 설정합니다. HTTPS 대상이라면 로그에 먼저 로컬 프록시 연결이 표시되고 이어서 CONNECT 터널 과정이 나타나는 경우가 많습니다. 200 Connection established는 터널이 만들어졌다는 뜻일 뿐, 이후 TLS 연결과 웹 요청까지 완료됐다는 의미는 아닙니다.

• Connection refused: 로컬 포트, 수신 주소, 코어 실행 여부부터 확인하세요.
• 로컬 포트에는 연결됐지만 CONNECT 또는 후속 요청이 시간 초과됨: 클라이언트 로그와 함께 정책 그룹, 노드, 대상 서버를 확인하세요.
• 프록시를 명시하면 성공하지만 일반 curl은 실패함: 환경 변수와 도구 자체 설정을 중점적으로 확인하세요.
• 인증서 오류: 시스템 시간, 인증서 신뢰 체인, 관리되는 네트워크를 확인하세요. 인증서 검증을 끄는 방식으로 장기간 해결하려 하지 마세요.

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

https_proxy는 HTTPS 대상에 사용할 프록시를 지정하며 변수값에는 http://를 사용할 수 있습니다. curl은 HTTP 프록시 변수로 소문자 http_proxy만 지원하고 대문자 HTTP_PROXY는 지원하지 않습니다. 다른 도구는 대소문자 지원 방식이 다를 수 있으므로 모든 프로그램이 똑같이 동작한다고 가정하지 마세요.

이 export 설정은 현재 셸과 이후에 실행되는 하위 프로세스에만 적용되며 이미 실행 중인 프로그램에는 영향을 주지 않습니다. 테스트에 성공하면 사용 중인 셸에 맞춰 ~/.zshrc나 ~/.bashrc 등의 시작 파일에 추가하세요. IDE 내장 터미널은 IDE 시작 당시의 오래된 환경 변수를 물려받을 수 있으므로 관련 프로세스를 종료한 뒤 다시 실행해야 합니다.

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

현재 창을 닫으면 이 값은 자동으로 유지되지 않습니다. Windows 데스크톱 프록시, WinHTTP 프록시, 프로세스 환경 변수는 서로 다른 설정 경로입니다. netsh winhttp show proxy의 결과만으로 브라우저나 curl의 동작 전체를 판단할 수는 없습니다. 대상 프로그램이 WinHTTP를 사용한다고 확인된 경우에만 해당 경로를 점검하세요.

남아 있는 환경 변수와 앱별 프록시 설정 정리

macOS와 Linux에서는 env | grep -i proxy, PowerShell에서는 Get-ChildItem Env:*proxy*를 실행할 수 있습니다. 이전 포트를 가리키는 ALL_PROXY, 대문자 변수, 범위가 지나치게 넓은 NO_PROXY를 중점적으로 확인하세요. curl에서는 프로토콜별 프록시 변수가 보통 ALL_PROXY보다 우선하며, 우회 목록에 대상이 포함되면 요청이 직접 연결될 수 있습니다.

Git만 실패한다면 git config --show-origin --get-regexp '.*proxy.*'로 설정 출처를 확인할 수 있습니다. 패키지 관리자도 별도의 프록시 설정을 저장할 수 있으므로 실제 사용하는 도구만 점검하고 모든 전역 설정을 한꺼번에 바꾸지 마세요. 테스트가 끝나면 Unix 셸에서 아래 명령어로 현재 세션의 일반적인 프록시 변수를 제거할 수 있습니다.

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

요청이 Clash에 들어온 경우: 규칙, DNS, 아웃바운드 경로 확인

브라우저와 curl의 대상이 모두 클라이언트 연결 목록에 나타난다면 프록시 진입 경로는 정상입니다. 이때 시스템 프록시를 계속 전환해도 도움이 되지 않습니다. 해당 연결의 세부 정보를 열고 대상 도메인, 적용된 규칙, 정책 그룹, 최종 노드를 차례로 확인하세요.

1. 규칙이 DIRECT로 연결: 의도한 동작인지 확인하세요. 규칙은 보통 위에서 아래 순서로 적용되므로 앞쪽의 직접 연결 규칙이 뒤쪽의 프록시 규칙보다 먼저 적용될 수 있습니다. 규칙 세트가 정상적으로 로드되었는지도 확인하세요.
2. 정책 그룹에서 DIRECT 선택: 프록시 정책 그룹에 해당하더라도 그룹 안에서 직접 연결을 선택했을 수 있습니다. 그룹 이름만 보지 말고 실제 선택된 항목을 확인하세요.
3. 노드 연결 실패: 같은 그룹의 다른 노드로 바꿔 동일한 대상에 다시 요청하세요. 지연 시간 테스트가 성공해도 테스트 대상에 연결됐다는 뜻일 뿐, 모든 웹사이트에 접속할 수 있는 것은 아닙니다.
4. DNS 오류: 로그를 확인해 대상 도메인 조회 실패인지, 프록시 서버 도메인 조회 실패인지, DNS 서버 연결 실패인지 구분하세요. 원인을 확인하기 전에 DNS, 규칙, 노드를 한꺼번에 바꾸지 마세요.

규칙 문제인지 확인하려면 잠시 ‘전역’ 모드로 전환하고 프록시 노드를 하나 지정해 한 번 테스트한 뒤 ‘규칙’ 모드로 되돌리세요. 전역 모드는 코어에 들어온 요청의 아웃바운드 선택만 바꾸며, 프록시를 사용하지 않는 앱의 요청까지 클라이언트로 강제로 보내지는 않습니다.

TUN 모드의 장단점: 프록시 설정을 읽지 않는 앱에 사용

브라우저와 프록시를 명시한 테스트는 정상인데 일부 앱이 시스템 프록시나 환경 변수를 전혀 읽지 않는다면 TUN 모드를 고려할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리하므로 더 많은 TCP 및 UDP 트래픽을 일괄적으로 다뤄야 할 때 유용합니다. 다만 실제 적용 범위는 라우팅, 제외 항목, 코어 설정, 플랫폼 권한에 따라 달라지며, 켠다고 모든 연결이 원격 노드를 거치는 것은 아닙니다.

• Windows: 클라이언트 요구에 따라 서비스 모드를 설치하거나 관리자 권한을 부여한 뒤 TUN을 켜고 가상 네트워크 인터페이스와 라우팅이 정상적으로 생성되는지 확인하세요.
• macOS: 클라이언트 안내에 따라 보조 서비스를 설치하고 관련 네트워크 권한을 허용하세요. 시작에 실패하면 권한과 라우팅 로그부터 확인하세요.
• Linux: TUN 장치를 사용할 수 있는지 확인하고 클라이언트 배포 방식에 따라 네트워크 관리에 필요한 권한을 부여하세요. 컨테이너나 제한된 환경에서는 가상 네트워크 인터페이스를 만들지 못할 수 있습니다.

mihomo의 일반적인 TUN 설정에는 enable, stack, auto-route, dns-hijack 등의 필드가 포함됩니다. 버전과 클라이언트에 따라 인터페이스에서 설정을 생성할 수도 있습니다. 현재 클라이언트에서 제공하는 스위치를 우선 사용하고 다른 플랫폼의 설정 전체를 기존 구독 설정에 덮어쓰지 마세요.

TUN을 점검할 때는 먼저 다른 VPN이나 유사한 라우팅 제어 클라이언트를 종료한 뒤 DNS, 웹, 터미널, 로컬 네트워크 서비스를 순서대로 테스트하세요. 회사 VPN, 가상 머신 네트워크 인터페이스, 컨테이너 네트워크는 자동 라우팅과 충돌할 수 있습니다. 켠 뒤 로컬 서비스에 연결할 수 없다면 모든 예외를 무작정 삭제하지 말고 제외된 네트워크 대역과 라우팅을 확인하세요.

curl, Git 등 일부 도구에만 프록시가 필요하다면 명시적 매개변수나 환경 변수를 사용하는 편이 문제를 찾기 쉽습니다. 프록시 설정을 지원하지 않는 앱까지 처리해야 할 때 TUN을 도입하세요. TUN을 켜자마자 네트워크가 끊기면 먼저 TUN을 꺼서 연결을 복구한 다음 권한, DNS, 라우팅 로그를 점검하세요.

재테스트 체크리스트: 같은 대상을 세 가지 경로로 확인

마지막으로 대상 도메인 하나를 정해 프록시를 명시한 curl, 브라우저, 별도 매개변수 없는 터미널 요청 순서로 테스트하세요. 매번 클라이언트에 연결이 들어왔는지, 어떤 규칙이 적용됐는지, 최종 아웃바운드가 무엇인지 기록합니다. 세 경로를 모두 확인한 뒤 필요한 PAC, 확장 프로그램, TUN 설정을 복구하고 임시로 높인 로그 수준을 평소 설정으로 되돌리세요.