Clash 시스템 프록시 작동 안 할 때 점검법: 브라우저 vs 터미널

먼저 3분만 투자해 기본부터 확인하기

「시스템 프록시가 작동 안 함」 문제는 사실 가장 기본적인 부분에서 막혀 있는 경우가 많습니다. 설정을 건드리기 전에 아래 4가지를 순서대로 확인하면 대부분 바로 원인을 찾을 수 있습니다.

1. 클라이언트가 실제로 실행 중인지 확인하세요. 트레이 아이콘이 보이고 메인 화면이 정상적으로 열리는지 체크하고, 최소화 후 몰래 종료된 상태는 아닌지 확인하세요.
2. 노드가 정상 작동하는지 확인하세요. 프록시 탭에서 현재 노드의 지연 시간을 테스트해 보고, 타임아웃이나 비정상적으로 높은 지연이 있다면 다른 노드로 교체하세요. 시스템 프록시는 입구일 뿐이라 노드가 막혀 있으면 입구를 제대로 열어도 소용없습니다.
3. 시스템 프록시가 실제로 시스템에 등록되었는지 확인하세요. 클라이언트에서 스위치가 「켜짐」으로 표시돼도 그것만으로는 부족하고, OS에서 실제 값을 확인해야 합니다. Windows는 「설정 → 네트워크 및 인터넷 → 프록시」에서 「프록시 서버 사용」을 확인하고, macOS는 「시스템 설정 → 네트워크 → 세부 정보 → 프록시」에서 웹 프록시와 보안 웹 프록시를 확인합니다. Linux(GNOME)는 「설정 → 네트워크 → 네트워크 프록시」에서 수동 모드 여부를 확인하세요. 주소는 127.0.0.1이어야 하고, 포트는 클라이언트와 일치해야 합니다.
4. 포트가 일치하는지 확인하세요. 클라이언트 설정 화면에 표시된 포트와 시스템에 등록된 포트가 반드시 같아야 합니다. 포트를 바꾸고도 스위치를 다시 켜지 않는 실수가 자주 발생합니다.

시스템 프록시 스위치가 실제로 하는 일

원리를 이해하면 시행착오를 절반은 줄일 수 있습니다. 이 스위치는 단 한 가지 일만 합니다: 「127.0.0.1 + 클라이언트 리스닝 포트」를 OS의 프록시 설정에 써넣는 것입니다. 이후 시스템 프록시를 따르는 앱—대부분의 브라우저와 데스크톱 소프트웨어—은 연결을 시도할 때 먼저 트래픽을 Clash 코어로 넘기고, 코어가 규칙에 따라 분기 처리합니다. 반면 시스템 프록시를 읽지 않는 앱은 전혀 영향을 받지 않는데, 커맨드라인 도구가 가장 대표적인 예입니다.

따라서 「스위치는 켰는데 효과가 없다」는 다음 세 가지 지점에서만 발생할 수 있습니다:

• 쓰기 실패: 시스템에 해당 설정이 실제로 등록되지 않은 경우로, 권한 부족, 보안 소프트웨어의 차단, 다른 프록시 소프트웨어의 선점이 흔한 원인입니다.
• 앱이 읽지 않음: 앱이 자체 프록시 설정을 사용하거나 시스템 프록시를 아예 참조하지 않는 경우입니다.
• 입구가 막힘: 설정은 제대로 등록됐지만 Clash의 포트가 리스닝되지 않거나 현재 노드가 사용 불가능한 경우입니다.

첫 번째와 세 번째는 앞 절의 기본 확인으로 대부분 걸러집니다. 나머지는 브라우저와 터미널로 나눠서 처리합니다.

브라우저 쪽: 먼저 확장 프로그램과 별도 설정을 확인

먼저 명령어 하나로 Clash 입구 자체가 정상인지 확인합니다. 터미널을 열고 프록시를 명시적으로 지정해 IP 조회 API에 접속해 보세요:

curl -x http://127.0.0.1:7890 https://api.ip.sb

정상이라면 노드의 출구 IP가 반환됩니다. 이 단계에서 실패하면 문제는 클라이언트나 노드 쪽이며 브라우저와는 무관하므로 앞 절로 돌아가서 처리하세요. 이 단계는 정상인데 브라우저에서만 작동하지 않는다면 아래 순서로 확인합니다:

1. 프록시 관련 확장 프로그램을 비활성화하세요. SwitchyOmega 같은 확장은 브라우저 프록시를 가로채며, 시스템 설정보다 우선순위가 높습니다. 일단 전부 끄고 테스트한 다음, 정상 작동이 확인되면 하나씩 켜서 어떤 확장이 프록시를 가로채고 있는지 찾아냅니다.
2. 시크릿(비공개) 창으로 비교 테스트하세요. 시크릿 모드는 기본적으로 확장을 로드하지 않으므로, 시크릿 창에서는 정상이고 일반 창에서는 비정상이라면 확장이 프록시를 가로채고 있다는 뜻입니다.
3. Firefox의 독립 설정을 확인하세요. Firefox의 프록시 설정은 시스템 패널과 별도로 동작합니다. 이전에 수동으로 변경한 적이 있다면 「설정 → 네트워크 설정」에서 「시스템 프록시 설정 사용」으로 다시 선택되어 있는지 확인하세요.
4. 남아 있는 자동 설정 스크립트를 정리하세요. 시스템 프록시에 「자동 구성 스크립트(PAC) 사용」 주소가 남아 있으면 브라우저는 Clash가 아니라 그 스크립트를 따르게 됩니다. 해당 옵션을 꺼주세요.
5. 출구 IP로 최종 비교 확인을 하세요. IP 조회 사이트를 열고 노드를 바꿔서 새로고침했을 때 출구 IP가 따라 바뀌면 경로는 정상 연결된 상태입니다. 특정 사이트만 안 열린다면 규칙이나 노드 문제이며, 더 이상 시스템 프록시 문제가 아닙니다.

터미널 쪽: 커맨드라인은 시스템 프록시를 읽지 않는다

가장 흔한 오해가 이것입니다: 터미널 및 그 안의 curl, git, npm은 기본적으로 시스템 프록시를 전혀 읽지 않으며, 스위치를 얼마나 오래 켜둬도 그대로 직접 연결됩니다. 터미널이 프록시를 사용하게 하려면 환경 변수를 따로 설정해야 합니다.

macOS / Linux(bash、zsh):

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:7890

Windows PowerShell:

$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"

Windows cmd:

set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890

설정 후 curl https://api.ip.sb로 확인해 보면 노드 IP가 반환되면 정상 적용된 것입니다. 그 외에도 기억해 둘 만한 세부 사항이 몇 가지 있습니다:

• 환경 변수는 현재 창에만 적용되며 창을 닫으면 사라집니다. 계속 유지하려면 셸 설정 파일(예: ~/.zshrc)에 추가하세요.
• 특정 명령어 하나만 프록시를 쓰게 하려면 macOS / Linux에서 임시로 앞에 붙일 수 있습니다: https_proxy=http://127.0.0.1:7890 curl https://api.ip.sb.
• 로컬 및 내부망 주소는 프록시를 거치지 않도록 설정하세요: export no_proxy=localhost,127.0.0.1.
• 터미널 프록시를 해제하려면: macOS / Linux는 unset http_proxy https_proxy all_proxy를 실행하고, PowerShell은 해당 변수를 빈 값으로 재설정하면 됩니다.
• git은 자체 설정을 사용하며 일부 환경에서는 환경 변수를 참조하지 않습니다: git config --global http.proxy http://127.0.0.1:7890으로 설정하고, git config --global --unset http.proxy로 해제합니다. 이는 HTTP(S) 원격에만 영향을 주며 SSH 원격에는 영향을 주지 않습니다.

포트 충돌: 리스닝 실패 시 스위치는 무용지물

다른 프로그램이 포트를 점유하고 있으면 Clash의 포트 리스닝이 실패합니다—스위치는 평소처럼 켜지고 시스템 설정도 평소처럼 등록되지만, 입구 뒤에서 트래픽을 받아줄 서비스가 없는 상태가 되어 「켠 것과 다름없는」 결과로 나타납니다. 먼저 어떤 프로그램이 포트를 점유하고 있는지 확인합니다. Windows(PowerShell 또는 cmd): ```bash netstat -ano | findstr :7890 ``` 결과가 나오면 포트가 이미 점유된 상태이며, 마지막 열이 점유 중인 프로세스의 PID입니다. `tasklist | findstr `로 어떤 프로그램인지 확인하세요. macOS / Linux: ```bash lsof -i :7890 ``` Linux에서는 `ss -lntp | grep 7890`도 사용할 수 있습니다. 출력된 프로세스가 자신의 Clash 클라이언트가 아니라면 충돌이 확정된 것입니다. 해결 방법은 두 가지입니다: - 포트 변경: 클라이언트 설정 화면에서 mixed 포트를 사용 중이지 않은 값(예: 7897)으로 바꾸고 저장한 뒤, 시스템 프록시 스위치를 껐다 다시 켜서 새 포트가 시스템에 다시 등록되도록 합니다. - 포트 양보: 가장 흔한 점유 원인은 제대로 종료되지 않은 다른 프록시 클라이언트나 이전에 비정상 종료되어 남은 프로세스입니다. 트레이에서 종료하거나 해당 프로세스를 직접 강제 종료하세요.

권한, 잔존 설정, 다중 클라이언트 충돌

포트가 정상인데도 여전히 작동하지 않는다면, 다음 세 가지 흔한 원인을 살펴보세요:

1. macOS에서 권한 요청을 취소한 경우. 시스템 프록시를 처음 켤 때 비밀번호 입력을 요구하는 인증 창이 뜨는데, 여기서 「취소」를 누르면 쓰기가 실패합니다—스위치는 켜진 것처럼 보이지만 실제로는 시스템에 등록되지 않은 상태입니다. 스위치를 다시 켜고 이번에는 인증을 완료하세요.
2. 보안 소프트웨어의 차단. Windows에서는 일부 보안 소프트웨어가 서드파티 프로그램의 시스템 프록시 변경을 차단합니다. 클라이언트를 신뢰 목록에 추가한 뒤 스위치를 다시 켜세요.
3. 다중 클라이언트 간 충돌. 두 개의 프록시 클라이언트를 동시에 실행하면 나중에 켠 쪽이 먼저 켠 쪽의 시스템 프록시 설정을 덮어씁니다. 먼저 켠 클라이언트가 「작동 안 함」으로 보이는 건 당연한 결과입니다. 한 번에 하나만 실행하세요.

반대 방향의 문제도 알아둘 필요가 있습니다: 클라이언트를 종료하기 전에 시스템 프록시를 끄지 않으면 시스템에는 127.0.0.1:7890 설정이 계속 남아 있는데 실제로는 리스닝하는 서비스가 없어, 「Clash를 끄면 오히려 인터넷이 끊기는」 현상이 나타납니다. 해결법은 클라이언트를 다시 열어 스위치를 한 번 껐다 켜거나, 시스템 프록시 설정에서 직접 꺼주는 것입니다.

기업이나 학교 기기에서 그룹 정책이나 프로파일로 프록시 설정이 잠겨 있다면, 수동으로 등록해도 즉시 원래대로 되돌아갑니다. 이런 환경에서는 시스템 프록시를 계속 붙잡고 있을 필요 없이 터미널 환경 변수를 바로 쓰거나, 다음 절의 TUN 모드를 참고하세요.

터미널 도구를 많이 쓴다면 TUN 모드로 전환

시스템 프록시의 본질적인 한계는 「앱의 협조가 필요하다」는 점입니다: 앱이 시스템 설정을 읽지 않으면 스위치가 아무리 켜져 있어도 소용없습니다. 평소 터미널에서 git, npm, docker를 자주 쓴다면 더 간편한 방법은 TUN 모드입니다—가상 네트워크 카드를 만들어 시스템 네트워크 계층에서 전역 트래픽을 가로채므로 앱을 가리지 않고, 커맨드라인 도구도 별도 설정 없이 자동으로 프록시를 거치게 됩니다.

mihomo 코어 기반 클라이언트(Clash Verge Rev, Clash Nyanpasu, FlClash 등)는 설정 화면에 TUN 스위치를 제공합니다. Windows와 macOS에서는 처음 켤 때 보통 서비스 모드 설치나 관리자 권한 인증이 한 번 필요합니다. TUN과 시스템 프록시는 동시에 켜도 서로 충돌하지 않습니다. TUN은 라우팅 계층에서, 시스템 프록시는 애플리케이션 계층에서 각각 작동합니다.

한 페이지로 보는 점검 체크리스트

점검이 막다른 길에 다다르면, 이 체크리스트를 처음부터 다시 확인해 보세요:

1. 클라이언트가 실행 중이고, 현재 노드의 지연 테스트가 통과되는지.
2. 시스템 프록시 설정에 127.0.0.1이 보이고, 포트가 클라이언트 설정 화면과 일치하는지.
3. curl -x http://127.0.0.1:7890 https://api.ip.sb 명령이 노드 IP를 반환하는지.
4. 브라우저에서 프록시 관련 확장을 모두 끄고 시크릿 창으로 비교 테스트했는지.
5. 터미널에서 http_proxy / https_proxy 환경 변수를 별도로 설정했는지.
6. netstat 또는 lsof로 포트 충돌이 없는지 확인하고, 포트 변경 후 스위치를 다시 켰는지.
7. 프록시 클라이언트는 하나만 실행하고, 종료 전에 시스템 프록시를 먼저 껐는지.
8. 터미널 사용이 많다면 TUN 모드로 전환해 전역 트래픽을 처리하는지.

「시스템 프록시가 작동 안 함」 문제는 대부분 세 번째 단계까지 확인하면 방향이 잡힙니다: 입구가 통하면 앱을 확인하고, 입구가 막혀 있으면 클라이언트와 포트를 확인하세요. 순서대로 점검하는 것이 클라이언트를 재설치하는 것보다 훨씬 빠릅니다.