먼저 현상 확인: 시스템 프록시가 실제로 켜져 있는지
"시스템 프록시가 작동하지 않는다"는 사실 모호한 표현입니다. 실제로는 프록시를 전혀 타지 않는 경우, 일부 프로그램만 프록시를 타지 않는 경우, 프록시는 타지만 규칙이 대상 노드를 잘못 판단한 경우 등 세 가지 다른 문제가 섞여 있을 수 있습니다. 점검 전에 기본 확인을 한 번 해두면 진단 시간을 크게 줄일 수 있습니다.
클라이언트 메인 화면을 열어 왼쪽 또는 상단의 "시스템 프록시" 스위치가 켜져 있는지 확인하세요. 별것 아닌 단계처럼 보이지만, 실제 지원 사례를 보면 상당수의 문의가 결국 스위치가 실수로 꺼져 있었거나, 시스템 재시작이나 클라이언트 업데이트 후 시스템 프록시 설정이 다시 기록되지 않은 경우로 귀결됩니다.
다음으로 포트를 확인합니다. Clash 코어는 기본적으로 HTTP(또는 HTTP+HTTPS 혼합) 포트 하나와 SOCKS5 포트 하나를 리스닝하며, 흔한 기본값은 7890(HTTP)과 7891(SOCKS)입니다. 시스템의 네트워크 프록시 설정 패널을 열어 주소와 포트가 클라이언트 설정 화면에 표시된 값과 일치하는지 하나씩 대조하세요. 클라이언트에서 포트를 사용자 지정 값으로 바꿨는데 시스템 프록시 설정이 여전히 옛 포트를 가리키고 있다면, 트래픽은 당연히 코어까지 들어가지 못합니다.
- 클라이언트의 "시스템 프록시" 스위치가 켜져 있는지;
- 클라이언트에 표시된 혼합 포트/HTTP 포트/SOCKS 포트가 시스템 프록시 설정과 일치하는지;
- 여러 프록시 도구가 동시에 시스템 프록시 설정을 점유하여, 나중에 실행된 쪽이 앞의 설정을 덮어쓴 것은 아닌지;
- 현재 선택된 노드 그룹의 전략이 "직접 연결" 또는 이미 실패한 노드로 되어 있지는 않은지.
주의: 일부 클라이언트는 설정 파일을 전환할 때 시스템 프록시 스위치를 초기화합니다. 구독이나 로컬 설정을 변경한 뒤에는 기억에만 의존하지 말고 스위치 상태를 다시 확인하는 것이 좋습니다.
브라우저 쪽 점검: 프록시 스위치, 포트, 확장 프로그램 충돌
브라우저는 "프록시를 타지 않는 것처럼 보이는" 현상이 가장 자주 나타나는 지점입니다. 원인은 대부분 Clash 자체가 아니라 브라우저 자체의 네트워크 설정 계층에 있습니다. 브라우저마다 시스템 프록시를 받아들이는 방식이 완전히 같지 않으므로, 아래 순서대로 범위를 좁혀가며 점검하는 것을 권장합니다.
브라우저가 시스템 프록시를 읽고 있는지 확인
대부분의 주요 브라우저는 기본적으로 시스템 프록시 설정을 따르지만, 일부 브라우저는 별도의 "내장 프록시" 옵션을 제공합니다. 이 옵션이 켜져 있으면 시스템 계층 설정을 무시하고 브라우저 자체에 저장된 주소를 사용합니다. 브라우저의 네트워크/프록시 설정 페이지를 열어 프록시 모드가 "시스템 프록시 사용" 또는 "자동 감지"로 되어 있는지, "수동 구성"으로 바뀌어 만료된 주소가 입력되어 있지는 않은지 확인하세요.
확장 프로그램으로 인한 충돌 점검
브라우저 확장 프로그램은 또 하나의 빈번한 문제 지점입니다. 일부 우회 도구, 광고 차단, 개인정보 보호 강화형 확장 프로그램은 스스로 프록시 설정을 가로채거나 PAC 스크립트를 주입하여 시스템 프록시와 충돌을 일으키며, "클라이언트 로그에 연결 기록이 전혀 없음"으로 나타납니다. 네트워크 관련 확장 프로그램을 모두 일시적으로 비활성화한 뒤 페이지를 새로고침해 다시 테스트해 보세요. 정상으로 돌아온다면 하나씩 다시 활성화하면서 충돌 대상을 특정하면 됩니다.
시크릿 창으로 대조 테스트
시크릿/개인정보 보호 창은 기본적으로 일반 확장 프로그램을 로드하지 않으므로 확장 프로그램 충돌을 확인하는 간편한 수단입니다. 시크릿 창에서는 프록시가 정상 작동하는데 일반 창에서는 안 된다면, 문제가 확장 프로그램이나 브라우저에 남아 있는 예전 프록시 설정 캐시에 있다고 거의 확신할 수 있습니다. 브라우저 네트워크 설정 캐시를 지우거나 관련 확장 프로그램을 재설치하면 해결됩니다.
팁: 주소 표시줄에 about:net-internals 같은 주소나 해당 브라우저의 네트워크 진단 페이지를 입력하면, 일부 브라우저는 현재 적용 중인 프록시 주소와 포트를 바로 보여줍니다. 이렇게 확인하는 것이 계속 추측하는 것보다 훨씭 확실합니다.
터미널 점검: 환경 변수, curl 테스트, 흔한 오해
터미널(명령줄) 프로그램은 일반적으로 시스템 수준의 GUI 프록시 설정을 읽지 않고 환경 변수에 의존합니다. 이 때문에 브라우저 프록시는 정상인데 git, curl, npm 같은 명령줄 도구는 여전히 외부 네트워크에 연결되지 않아 혼란스러운 경우가 많습니다.
먼저 Clash 클라이언트가 해당 플랫폼의 터미널 프록시 기록 기능을 켜두었는지 확인하세요(일부 클라이언트는 시스템 프록시가 켜지면 http_proxy/https_proxy 환경 변수를 함께 설정해 주지만, 일부는 수동 설정이 필요합니다). 터미널에서 현재 환경 변수를 직접 출력해 확인할 수 있습니다:
echo $http_proxy
echo $https_proxy
echo $all_proxy출력이 비어 있다면 현재 터미널 세션에 프록시 환경 변수가 없다는 뜻이므로 수동으로 설정해야 합니다. 포트는 클라이언트에 실제로 표시된 값을 기준으로 하세요:
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export all_proxy="socks5://127.0.0.1:7891"설정 후 curl로 상세 정보를 포함한 요청을 보내 실제로 프록시를 경유하는지 확인합니다:
curl -v -x http://127.0.0.1:7890 https://example.org이 명령이 정상적으로 응답을 받아오는 반면 -x 옵션 없는 일반 요청은 실패하거나 다른 결과로 이어진다면, 프록시 경로 자체에는 문제가 없고 대상 프로그램이 환경 변수를 읽지 못하는 것이 원인입니다. 흔한 원인은 변수가 현재 터미널 세션에서만 유효하다는 점입니다. 새로 연 터미널 창이나 GUI에서 실행한 프로그램(터미널이 아닌 데스크톱 아이콘으로 실행한 앱 등)은 이런 변수를 전혀 물려받지 않습니다. export 문을 셸의 시작 설정 파일(.zshrc, .bashrc 등)에 넣고 다시 로드하거나, 시스템 수준 환경 변수로 통일해서 설정하면 "될 때도 있고 안 될 때도 있는" 것 같은 착각을 피할 수 있습니다.
Windows 터미널의 추가 단계
Windows의 PowerShell과 CMD 역시 GUI 시스템 프록시 설정을 자동으로 물려받지 않으므로, 세션 변수를 별도로 설정하거나 시스템 환경 변수 패널에서 영구적으로 설정해야 합니다:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"설정 후에도 curl.exe -v나 Invoke-WebRequest로 한 번 더 검증 요청을 보내, "브라우저에서 되니까 터미널도 당연히 될 것"이라고 단정하지 않도록 하세요.
우회 규칙으로 인한 가짜 실패
또 다른 유형의 문제는 프록시가 작동하지 않는 것이 아니라, 프록시는 정상 작동하는데 규칙이 해당 트래픽을 "직접 연결해야 함"으로 판단해버려서 마치 프록시를 전혀 안 타는 것처럼 보이는 경우입니다. 이런 상황은 설정 파일의 rules 섹션이나 시스템 프록시의 우회 목록(bypass list) 설정이 잘못되었을 때 가장 흔하게 나타납니다.
시스템 프록시 설정에는 보통 "다음 주소는 프록시를 사용하지 않음"이라는 입력란이 있고, 기본값으로 localhost나 내부망 주소대가 포함되어 있을 수 있습니다. 테스트 중인 대상 사이트나 와일드카드 전체를 실수로 이 우회 목록에 추가했다면, 클라이언트 상태와 무관하게 해당 주소는 영원히 프록시를 경유하지 않습니다. 점검 시에는 먼저 우회 목록을 비워두고 대조 테스트를 해보는 것이 좋습니다.
설정 파일 수준의 규칙도 함께 확인할 가치가 있습니다. 흔히 볼 수 있는 규칙 예시는 다음과 같으며, 지나치게 범위가 넓은 직접 연결 매칭이 앞쪽에 배치되어 있지 않은지가 핵심 확인 포인트입니다:
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY테스트 대상이 마침 GEOIP,CN,DIRECT 같은 규칙보다 먼저 매칭된다면, 노드와 포트가 전부 정상이라도 해당 요청은 프록시 노드를 거치지 않고 곧바로 통과됩니다. 클라이언트 로그 패널을 열어 상세 로그 레벨로 전환한 뒤 대상 주소에 다시 접속해서, 이 연결이 정확히 어떤 규칙에 매칭되었는지, 최종적으로 어떤 정책 그룹이 사용되었는지를 확인하세요. 이것이 "규칙 오판"과 "프록시 미작동"을 구분하는 가장 직접적인 증거입니다.
점검 순서 권장: 로그에서 매칭된 규칙 확인 → 우회 목록 확인 → 포트와 스위치 확인 → 마지막으로 노드 자체의 가용성 의심, 이 순서로 진행하는 것이 가장 효율적입니다. 무작정 클라이언트를 재설치하거나 구독을 바꾸는 것부터 시작하지 마세요.
위 항목이 모두 정상이라면 TUN 모드를 고려해 보세요
시스템 프록시는 애플리케이션 계층 프로토콜(HTTP/SOCKS) 전달 방식에 의존합니다. 일부 프로그램은 시스템 프록시 설정을 따르지 않거나 독자적인 네트워크 스택을 사용하기 때문에, 원천적으로 시스템 프록시를 경유하지 않습니다. 이런 경우는 시스템 프록시 모드로는 근본적으로 해결하기 어렵습니다. 반복 점검 후 프록시 경로 자체는 문제가 없고 일부 완고한 프로그램만 시스템 프록시 계층을 우회하고 있다는 것이 확인되었다면, TUN 모드로 전환해 코어가 네트워크 계층에서 모든 트래픽을 직접 처리하도록 하는 것을 고려할 수 있습니다. 이렇게 하면 개별 프로그램이 프록시 설정을 읽는지 여부에 더 이상 의존하지 않게 됩니다. TUN 모드는 처리 범위가 훨씭 포괄적이지만 권한과 네트워크 어댑터 설정 요구 사항이 더 높으므로, 시스템 프록시 점검에서 명확히 무효라는 결론이 나온 뒤에 다음 단계로 고려하는 것을 권장합니다. 기본 점검을 건너뛰고 처음부터 TUN 모드로 시작하지는 마세요.