시스템 프록시가 작동하지 않을 때: 브라우저와 터미널을 각각 점검하는 전체 절차

"시스템 프록시가 켜져 있다"가 "모든 트래픽이 프록시를 탄다"를 의미하지 않는 이유

Clash 클라이언트의 "시스템 프록시" 스위치는 본질적으로 운영체제나 데스크톱 환경의 프록시 설정 항목을 수정하는 기능입니다(Windows의 WinINet 설정, macOS의 네트워크 서비스 프록시, Linux의 GSettings 또는 환경 변수). 이런 설정은 시스템 프록시 설정을 능동적으로 읽어오는 프로그램에만 적용되며, 대표적으로 브라우저와 일부 GUI 앱이 여기에 해당합니다. 네트워크 계층에서 강제로 트래픽을 전달하는 방식이 아니므로 프로세스가 이 설정을 무시할 수 있습니다 — 많은 사람들이 "프록시는 분명 켜져 있는데 특정 프로그램만 프록시를 타지 않는다"고 느끼는 근본 원인이 바로 여기에 있습니다.

커맨드라인 도구(curl, wget, git, 패키지 매니저 등)는 대부분 시스템 프록시 설정을 읽지 않고 환경 변수(http_proxy, https_proxy, all_proxy)를 읽습니다. 즉 시스템 프록시가 켜져 있는지와 터미널이 프록시를 탈 수 있는지는 완전히 별개의 문제이며, 각각 다른 점검 방식이 필요합니다.

프로그램을 구분하지 않고 모든 트래픽을 강제로 프록시에 태워야 한다면, 유일하게 확실한 방법은 TUN 모드입니다 — 네트워크 인터페이스 계층에서 트래픽을 가로채므로 앱이 프록시 설정을 능동적으로 읽는지와 무관하게 동작합니다. 이 글 뒷부분에서 시스템 프록시와 TUN 모드의 선택 기준을 구체적으로 다룹니다.

점검을 시작하기 전 먼저 확인할 것: Clash 자체가 정상적으로 실행 중이고 사용 가능한 노드가 있는지입니다. 코어가 시작되지 않았거나 구독 노드가 전부 실패한 상태라면 시스템 프록시 설정이 아무리 정확해도 연결이 성립되지 않습니다. 이런 경우 먼저 실행 로그를 확인해 프록시 포트가 정상적으로 리슨(listen) 중인지 확인하는 것이 좋습니다.

브라우저가 프록시를 타지 않을 때의 점검 절차

브라우저가 프록시를 타지 않는 경우는 대개 네 가지 원인으로 나뉩니다: 프록시 스위치가 적용되지 않음, 브라우저에 별도의 프록시 설정이 있음, 확장 프로그램이나 보안 소프트웨어의 차단, DNS가 프록시를 타지 않아 발생하는 부분적 누출입니다. 아래 순서대로 하나씩 점검합니다.

1단계: 시스템 프록시 스위치 상태 확인

Clash 클라이언트 설정 페이지를 열어 "시스템 프록시"가 켜져 있는지 확인하고, 리슨 포트(대개 HTTP/Mixed 포트, 기본값은 7890 부근)도 함께 확인합니다. 일부 클라이언트는 설정 파일을 전환할 때 이 스위치를 초기화하며, 시스템 업그레이드나 재부팅 후 시스템이 이를 다시 꺼버리는 경우도 있습니다.

Windows: "설정 → 네트워크 및 인터넷 → 프록시"를 열어 "설정 스크립트 사용" 또는 "프록시 수동 설정"이 로컬 주소와 해당 포트를 정확히 가리키는지 확인합니다.
macOS: "시스템 설정 → 네트워크 → 사용 중인 네트워크 서비스 → 세부사항 → 프록시"를 열어 웹 프록시(HTTP)와 보안 웹 프록시(HTTPS)가 모두 체크되어 있고 올바른 포트가 입력되었는지 확인합니다.
Linux(GNOME 등 데스크톱 환경): "설정 → 네트워크 → 네트워크 프록시"에서 "수동" 모드로 되어 있는지 확인합니다("자동"이나 "꺼짐"이 아니어야 합니다).

2단계: 브라우저 자체의 별도 프록시 설정 배제

일부 브라우저(특히 Firefox)는 기본적으로 시스템 프록시를 따르지 않고 자체 연결 설정을 사용합니다. Firefox에서 프록시를 수동으로 설정했거나 "프록시 사용 안 함"을 선택한 경우, 시스템 프록시가 정상이어도 적용되지 않습니다. 확인 경로:

Firefox: 설정 → 일반 → 네트워크 설정 → "시스템 프록시 설정 사용"이 선택되어 있는지 확인합니다.
Chrome / Edge / 대부분의 Chromium 기반 브라우저: 기본적으로 시스템 프록시를 따르므로 보통 별도 설정이 필요 없지만, 기업 정책이나 일부 확장 프로그램이 이 동작을 덮어쓸 수 있으므로 브라우저의 프록시 설정 페이지에서 잠겨 있는지 확인합니다.

3단계: 확장 프로그램과 보안 소프트웨어의 차단 확인

광고 차단 확장, 기업 보안 클라이언트, 일부 VPN 클라이언트는 네트워크 요청 경로를 강제로 수정하거나 프록시 설정을 가로챌 수 있습니다. 먼저 브라우저의 시크릿/비공개 모드(기본적으로 확장이 비활성화됨)에서 테스트해 정상으로 돌아오는지 확인합니다. 정상으로 돌아온다면 특정 확장이 원인이므로 하나씩 비활성화하며 원인을 찾습니다.

4단계: DNS 요청도 프록시를 타는지 확인

브라우저가 "연결은 되지만 매우 느리다" 또는 "일부 사이트는 정상이지만 일부는 이상하다"는 증상은 DNS 누출이 원인인 경우가 많습니다 — 웹페이지 데이터는 프록시를 타지만 도메인 해석은 로컬 DNS를 사용해 통신사나 로컬 네트워크에 의해 미리 간섭받는 경우입니다. 이는 엄밀히 말해 "프록시가 작동하지 않는" 상황은 아니지만 증상이 유사하므로, 규칙 모드에서 DNS 하이재킹이나 fake-ip 모드가 켜져 있는지 함께 확인하는 것이 좋습니다.

프록시 경로 자체가 정상인지만 확인하고 싶다면, 특정 사이트로 먼저 테스트하기보다 IP 조회 페이지에 직접 접속해 출구 IP가 바뀌는지 관찰하는 것이 좋습니다 — 특정 사이트가 이상한 것은 규칙 분기(rule) 때문에 직접 연결 그룹으로 분류된 것일 수 있으며, 프록시 전체가 실패했다는 뜻은 아닙니다.

커맨드라인 터미널이 프록시를 타지 않을 때의 점검 절차

터미널 도구가 프록시를 타는지 여부는 해당 도구가 프록시 환경 변수를 읽는지, 변수가 올바르게 설정되어 현재 세션에 전달되는지에 따라 결정됩니다. 점검 순서는 다음과 같습니다.

1단계: 환경 변수가 설정되어 있는지 확인

macOS / Linux 터미널에서 실행:

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

Windows에서 PowerShell을 사용할 경우 해당 명령은 다음과 같습니다:

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

2단계: 변수가 올바른 설정 파일에 기록되었는지 확인

export로 임시 설정한 변수는 현재 터미널 세션에만 유효하며, 새로 연 터미널 창은 이를 이어받지 않습니다. 장기적으로 적용하려면 shell의 시작 설정 파일(예: ~/.zshrc, ~/.bashrc, ~/.bash_profile 등, 사용 중인 shell과 시스템에 따라 다름)에 작성해야 하며, 수정 후에는 source ~/.zshrc를 실행하거나 터미널을 새로 열어야 적용됩니다.

3단계: 도구 자체가 해당 변수를 읽는지 확인

도구마다 따르는 규칙이 서로 다릅니다:

curl, wget: 기본적으로 http_proxy/https_proxy를 읽습니다. 대소문자는 보통 구분하지 않지만 소문자로 통일하는 것을 권장합니다.
git: 시스템 환경 변수를 자동으로 전달받지 않으므로 git config --global http.proxy와 https.proxy를 별도로 설정해야 합니다.
패키지 매니저(npm, pip, apt 등): 각자 독립된 프록시 설정 항목이 있으며 환경 변수를 인식하지 못하는 경우가 많아, 보통 해당 설정 파일에 프록시 주소를 별도로 지정해야 합니다.
Docker, Docker Compose: 컨테이너 안의 프로세스는 기본적으로 호스트의 환경 변수를 공유하지 않으므로, Docker 설정이나 docker-compose.yml에 프록시 변수를 명시적으로 전달하거나 Docker 데몬에 별도로 프록시를 설정해야 합니다.

4단계: 최소 명령으로 프록시 경로 검증

도구 자체의 로직 간섭을 배제하고 curl로 프록시 포트가 실제로 사용 가능한지 직접 테스트합니다:

curl -x http://127.0.0.1:7890 -I https://www.example.com

이 명령이 정상적으로 응답 헤더를 반환한다면 프록시 포트 자체는 정상 작동 중이며, 문제는 특정 도구가 프록시 설정을 제대로 읽지 못한 데 있습니다. 이 명령마저 타임아웃되거나 오류가 나면 문제는 Clash 클라이언트나 노드 자체에 있으므로 클라이언트로 돌아가 노드 연결 상태와 리슨 포트를 확인해야 합니다.

✓

터미널 관련 문제를 점검할 때는 "curl에 -x 옵션으로 프록시를 직접 지정해 테스트하기"를 첫 번째 검증 단계로 삼는 것이 좋습니다 — 이렇게 하면 문제 범위를 "프록시 포트" 또는 "특정 도구의 설정" 둘 중 하나로 빠르게 좁힐 수 있어, 도구 자체의 복잡한 설정 항목에서 헤매는 것을 피할 수 있습니다.

시스템 프록시 스위치와 TUN 모드, 무엇을 선택해야 할까

시스템 프록시와 TUN 모드는 적용 범위가 완전히 다른 두 가지 방식이므로, 선택 전에 자신의 필요 사항을 먼저 명확히 하는 것이 좋습니다.

시스템 프록시 스위치의 특징

시스템 프록시는 운영체제나 브라우저가 읽는 프록시 설정 항목만 수정합니다. 장점은 부담이 적고 전환이 유연하며 시스템 네트워크 스택을 침범하지 않는다는 점입니다. 단점은 적용 범위가 완전하지 않다는 점입니다 — 시스템 프록시 설정을 능동적으로 읽지 않는 프로그램(일부 커맨드라인 도구, 게임, 일부 백그라운드 서비스)은 프록시가 적용되지 않으므로 환경 변수나 앱 내 프록시 옵션을 별도로 설정해야 합니다.

TUN 모드의 특징

TUN 모드는 시스템에 가상 네트워크 인터페이스를 생성하고, Clash 코어가 이 인터페이스를 지나는 모든 트래픽을 가로채며, 앱이 프록시를 능동적으로 설정했는지 여부와 무관하게 동작합니다. 즉 원래 "시스템 프록시를 타지 않던" 커맨드라인 도구, 백그라운드 서비스, 게임 등의 트래픽도 통합적으로 처리되어 전역 프록시에 더 가까운 효과를 냅니다. 대가는 설정이 더 복잡하다는 점입니다(보통 프로세스 모드를 추가로 켜거나 라우팅 테이블·방화벽 규칙을 처리해야 함). 일부 시스템에서는 가상 네트워크 카드를 생성하려면 관리자/root 권한이 필요합니다.

두 방식의 선택 기준

브라우저와 일반적인 데스크톱 앱만 프록시를 타면 충분한 경우: 시스템 프록시 스위치를 우선 사용합니다. 설정이 간단하고 문제가 생겨도 특정 소프트웨어로 원인을 쉽게 좁힐 수 있습니다.
커맨드라인 도구, 스크립트 작업, 백그라운드 서비스까지 통합적으로 프록시를 태워야 하고 하나씩 환경 변수를 설정하고 싶지 않은 경우: TUN 모드를 우선 고려합니다. 한 번의 설정으로 대부분의 상황을 커버할 수 있습니다.
세밀한 분기 제어(특정 프로그램은 직접 연결, 특정 프로그램은 프록시)가 동시에 필요한 경우: TUN 모드에 프로세스 규칙이나 IP 대역 규칙을 함께 사용하면 도구별로 일일이 프록시를 설정하는 것보다 편리하지만, 규칙 설정 방법을 이해하는 데 시간을 들여야 합니다.
연결 이상이 발생했을 때는 먼저 현재 시스템 프록시를 쓰고 있는지 TUN 모드를 쓰고 있는지 확인한 뒤 그에 맞게 점검합니다 — 두 방식의 오류 증상과 점검 경로는 서로 다르므로 섞어서 점검하면 헛수고를 하기 쉽습니다.

TUN 모드를 켠 뒤에도 일부 트래픽이 프록시를 우회한다면, 대개 라우팅 테이블이나 방화벽 규칙의 충돌이 원인입니다. 먼저 다른 VPN이나 네트워크 가속 도구를 임시로 끈 뒤 다시 테스트해, 여러 네트워크 제어 도구가 서로 충돌할 가능성을 배제하는 것이 좋습니다.

흔히 오판되는 상황과 점검할 때의 마음가짐

시스템 프록시 관련 문제에서는 몇 가지 현상이 자주 "프록시 미작동"으로 오판되지만, 실제 원인은 프록시 설정 자체에 있지 않은 경우가 많습니다:

규칙 분기로 특정 사이트가 직접 연결된 경우: 설정 파일에 특정 도메인이나 IP 대역에 대한 직접 연결 규칙이 있다면, 해당 사이트가 프록시를 거치지 않는 것은 의도된 동작이며 오류가 아닙니다.
노드 자체의 연결 이상: 프록시 설정은 정확하지만 노드가 실패한 경우로, 증상은 "웹페이지가 열리지 않는다"로 동일하게 나타나므로 먼저 클라이언트에서 노드의 지연과 연결 상태를 별도로 테스트해야 합니다.
DNS 캐시가 갱신되지 않은 경우: 프록시나 노드를 전환한 뒤에도 로컬 DNS 캐시가 이전 해석 결과를 여전히 가리킬 수 있으므로, 점검 전에 시스템 DNS 캐시를 비우거나 네트워크 서비스를 재시작하는 것이 좋습니다.
여러 프록시 도구가 동시에 실행 중인 경우: 다른 프록시 소프트웨어나 VPN이 함께 켜져 있으면 시스템 프록시 설정이 나중에 실행된 도구에 의해 덮어써질 수 있으므로, 점검 시 현재 네트워크 설정을 수정하는 도구가 하나뿐인지 먼저 확인하는 것이 좋습니다.

전체적인 점검 흐름은 다음과 같이 정리할 수 있습니다: 먼저 Clash 자체가 정상적으로 실행 중이고 노드가 사용 가능한지 확인한 뒤, 시스템 프록시 스위치나 환경 변수 설정이 올바른지 확인하고, 마지막으로 특정 앱이 이 설정을 따르고 있는지 확인합니다. 이 순서대로 단계별로 검증하면 잘못된 계층에서 반복적으로 조정하다가 원인을 찾지 못하는 상황을 피할 수 있습니다.