먼저 "시스템 프록시"를 두 경로로 나눠 보기
"시스템 프록시"라는 말 때문에 하나의 통합 스위치처럼 오해하기 쉽지만, 실제로 운영체제 차원의 프록시 설정은 시스템 프록시 설정을 따르는 애플리케이션에만 적용됩니다. 그리고 이 "따른다"는 개념은 완전히 별개인 두 경로로 나뉘어 있습니다:
- 브라우저 경로: Chrome, Edge, Firefox 등 주요 브라우저는 Windows/macOS에서 기본적으로 시스템 프록시 설정 항목을 읽어들입니다. 이 경로는 운영체제의 네트워크 설정 패널에서 제어합니다.
- 터미널/명령줄 경로: 터미널의
curl,git, 패키지 관리자 등은 시스템 설정 패널을 인식하지 못하고,http_proxy,https_proxy같은 환경 변수를 인식합니다. 시스템 프록시 스위치는 이들에게 전혀 영향을 주지 않습니다.
그래서 "Clash를 켰는데 안 된다"는 피드백이 많이 나오는 겁니다. 사실 적용 범위 자체가 터미널을 포함하지 않는데, 문제는 정확히 터미널 경로가 설정되지 않았다는 점에 있죠. 반대로 터미널은 되는데 브라우저는 직접 연결로 나간다고 하는 경우도 있는데, 이는 대부분 시스템 프록시 설정 항목 자체가 제대로 반영되지 않았거나 예외 목록에 막혀 있는 경우입니다.
Clash 계열 클라이언트는 실행 후 크게 두 가지만 처리합니다. 로컬에서 프록시 포트(HTTP/SOCKS/혼합 포트)를 리스닝하고, 규칙에 따라 트래픽을 각 노드로 분배하는 것뿐입니다. 시스템 내 다른 프로그램이 이 포트로 트래픽을 보낼지는 시스템 프록시 설정이나 환경 변수가 올바르게 구성됐는지에 달려 있으며, 이는 운영체제의 역할이지 Clash 코어의 역할이 아닙니다.
1단계: Clash가 실제로 리스닝 중인지 확인하기
시스템 프록시 설정이나 환경 변수를 의심하기 전에, 먼저 포트 자체가 열려 있는지 확인하세요. 이 단계만으로도 "가짜 오작동"의 절반을 걸러낼 수 있습니다.
- 클라이언트의 연결/포트 설정 페이지를 열어 현재 HTTP 포트(기본값으로 흔히 7890)와 혼합 포트 사용 여부를 확인합니다.
- 시스템 프록시 스위치를 거치지 않고 명령줄로 직접 해당 포트를 테스트해 리스닝 여부만 순수하게 검증합니다:
HTTP 응답 헤더(301/302라도)를 받으면 포트 자체는 정상이고 문제는 시스템 프록시 계층에서 연결이 안 된 것입니다. 반면 연결이 즉시 거부된다면 클라이언트가 실행되지 않았거나 포트가 변경된 상태이니, 먼저 이 부분을 해결한 뒤 다음 단계로 넘어가세요.curl -x http://127.0.0.1:7890 https://www.google.com -I - Windows에서는
netstat -ano | findstr 7890, macOS/Linux에서는lsof -i :7890으로 해당 포트를 점유한 프로세스가 실제로 Clash인지, 다른 프로그램이 선점하지 않았는지 확인하세요.
| 포트 종류 | 일반적인 기본값 | 주요 용도 |
|---|---|---|
| HTTP 포트 | 7890 | 브라우저 시스템 프록시, 대부분의 터미널 도구 |
| SOCKS 포트 | 7891 | SOCKS5를 요구하는 일부 클라이언트 |
| 혼합 포트(mixed-port) | 설정에 따라 다름 | 같은 포트로 HTTP와 SOCKS 요청을 동시에 처리 |
| 컨트롤 패널 포트 | 9090 | RESTful API, 프록시 전달과는 무관 |
브라우저 경로: 시스템 프록시가 왜 안 먹히는가
브라우저 경로 오작동은 주로 다음 세 지점에서 발생합니다. 순서대로 점검하세요:
- 시스템 프록시 스위치가 실제로는 켜지지 않은 경우 — 클라이언트의 "시스템 프록시로 설정"은 연동형 스위치라 일부 버전은 재시작 후 이전 상태로 자동 복원되지 않습니다. 기억에 의존하지 말고 현재 켜져 있는지 직접 확인하세요.
- 브라우저에 별도의 프록시 설정이 있는 경우 — 대부분의 브라우저는 기본적으로 시스템을 따르지만, 이전에 "수동 프록시 설정"을 만졌거나 프록시 관리 확장을 설치했다면 브라우저가 시스템 설정을 무시하고 자체 설정을 우선 적용합니다. 이 경우 브라우저 프록시 모드를 "시스템 설정 사용"으로 되돌리거나 관련 확장을 비활성화하세요.
- 기업/교육 네트워크의 그룹 정책 덮어쓰기 — 일부 업무용 PC는 그룹 정책으로 네트워크 설정을 통합 관리하는데, 시스템 프록시 항목이 체크되어 있어도 실제 브라우징 동작은 정책 계층에 의해 덮어써집니다. 이런 환경에서는 시스템 프록시 설정을 건너뛰는 TUN 모드를 바로 사용하는 걸 권장합니다(글 마지막 부분 참고).
브라우저의 시크릿/프라이버시 창은 별도의 네트워크 설정 캐시를 유지하는 경우가 있어, 일반 창에서 적용됐다고 해서 시크릿 창에도 자동으로 반영되는 건 아닙니다. "일부 창은 되고 일부는 안 되는" 상황이라면 먼저 시크릿 창을 새로 열어 다시 확인해 보세요.
터미널 경로: 환경 변수와 셸 설정
터미널은 시스템 프록시 패널을 읽지 않고 환경 변수를 인식합니다. 가장 흔히 쓰는 것은 http_proxy, https_proxy, all_proxy입니다(소문자가 표준이며, 대문자 형태는 도구마다 호환성이 다릅니다). 임시로 테스트하려면 현재 터미널 세션에서 바로 export하면 됩니다:
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"이 방식은 현재 터미널 창에만 적용되며 창을 닫으면 사라집니다. 터미널을 열 때마다 자동으로 적용되게 하려면 셸의 시작 설정 파일에 해당 줄을 추가해야 합니다. bash 사용자는 ~/.bashrc 또는 ~/.bash_profile에, zsh 사용자(macOS 기본 셸)는 ~/.zshrc에 작성하고, 작성 후 source ~/.zshrc를 실행하면 터미널을 재시작하지 않고도 현재 창에 즉시 반영됩니다.
흔히 빠지는 함정 세 가지:
- 잘못된 설정 파일에 작성한 경우 — macOS의 기본 셸은 이미 zsh로 바뀌었는데, 예전 튜토리얼을 그대로 따라
.bashrc를 수정하는 경우가 많습니다. 그러면 새로 연 터미널은 아예 읽어들이지 못합니다.echo $SHELL로 현재 사용 중인 셸을 먼저 확인하세요. - 포트 번호가 실제와 다른 경우 — 클라이언트에서 포트를 바꾸거나 설정 파일을 재설치한 뒤 환경 변수에 고정해 둔 포트 번호를 갱신하지 않은 경우입니다. 이런 문제는 터미널에서만 나타나며 브라우저는 시스템 프록시 설정을 따르기 때문에 오히려 정상 작동합니다. 양쪽 동작이 다르다면 먼저 포트 번호를 대조해 보세요.
- 일부 도구는 자체 설정 항목을 별도로 읽어들입니다— 예를 들어 Git은
git config --global http.proxy에 별도로 설정된 프록시 주소를 우선적으로 읽어들이므로, 환경 변수가 정확해도 Git은 자체 설정 항목을 따릅니다. 다음을 추가로 실행해야 합니다:git config --global http.proxy http://127.0.0.1:7890 git config --global https.proxy http://127.0.0.1:7890
환경 변수 설정이 끝나면 curl -v https://ipinfo.io/ip로 출력된 IP가 노드가 위치한 지역의 IP로 바뀌었는지 확인하세요. 명령어에 에러가 났는지만 볼 게 아닙니다 — 에러가 없다고 해서 실제로 프록시를 탄 것은 아니며, 직접 연결로도 접속에 성공하는 경우가 있습니다.
PAC 잔여 설정과 프록시 예외 목록
이전에 PAC 파일 기반 프록시 도구(자동 구성 스크립트 모드)를 사용한 적이 있다면, 이를 제거하거나 Clash로 전환한 뒤에도 시스템에 예전 PAC 주소가 지워지지 않고 남아 있을 수 있습니다. 그러면 시스템 프록시 패널에는 수동으로 지정한 IP+포트가 아니라 "설정 스크립트 사용"이 표시되며, 이 잔여 설정의 우선순위가 수동 프록시보다 높은 경우가 많아 시스템 프록시를 켰는데도 여전히 직접 연결되거나 접속에 문제가 생기는 형태로 나타납니다. 확인 방법:
- Windows: "설정 → 네트워크 및 인터넷 → 프록시"를 열어 "설정 스크립트 사용"이 켜져 있는지 확인하고, 켜져 있다면 먼저 끄고 "수동으로 프록시 설정"을 별도로 켜세요.
- macOS: 시스템 설정 → 네트워크 → 해당 네트워크 서비스의 세부 정보 → 프록시에서 "자동 프록시 구성"에 예전 PAC 주소가 체크되어 있는지 확인하고, "웹 프록시(HTTP)"와 "보안 웹 프록시(HTTPS)" 두 항목에 각각 Clash의 포트가 입력되어 있는지 확인하세요.
또 하나 놓치기 쉬운 부분은 프록시 예외 목록(no_proxy / bypass list)입니다. 시스템 프록시 설정에는 보통 "이 주소들에는 프록시 서버를 사용하지 않음"이라는 항목이 있고, 기본적으로 localhost, 127.* 같은 로컬 주소가 포함되어 있는 게 정상입니다. 하지만 일부 설치 패키지나 예전 설정이 이 목록에 광범위한 와일드카드 규칙을 채워 넣어, 정상적인 사이트 대부분이 예외 목록에 포함되어 접속할 때 전부 직접 연결로 빠지는 경우가 있습니다. 확인할 때는 예외 목록에 예상 범위를 벗어난 도메인이 대량으로 등록되어 있는지가 핵심이고, 터미널에서는 이에 해당하는 환경 변수가 no_proxy이니 별도로 확인해 보세요:
echo $no_proxyno_proxy에 *나 지나치게 광범위한 와일드카드(예: 최상위 도메인 전체)가 들어 있으면 터미널 프록시가 무의미해져 모든 요청이 예외로 판정되어 직접 연결로 처리됩니다. 이런 경우는 아예 초기화한 뒤 필요한 로컬 주소만 남겨서 다시 작성하는 것을 권장합니다.
점검 순서 체크리스트와 대안
위 내용을 순서대로 따라갈 수 있는 체크리스트로 정리했습니다. "시스템 프록시는 켰는데 안 된다"는 상황이면 위에서부터 하나씩 확인하세요:
curl -x로 포트를 직접 테스트해 Clash가 실제로 리스닝 중이고 포트 번호가 맞는지 확인합니다.- 클라이언트의 "시스템 프록시로 설정" 스위치가 실제로 켜져 있는지 확인합니다.
- 브라우저에 별도의 수동 프록시가 설정되어 있거나 프록시 관리 확장이 설치되어 있는지 확인하고, 시스템 설정을 따르도록 통일합니다.
- 시스템 프록시 패널에 예전 PAC 스크립트 주소가 남아 있는지 확인하고, 초기화 후 IP와 포트를 수동으로 지정합니다.
- 시스템 프록시 예외 목록과 터미널의
no_proxy변수를 확인해 과도하게 광범위한 와일드카드 규칙을 정리합니다. - 터미널 환경 변수는 현재 사용 중인 셸(bash/zsh)에 맞는 설정 파일에 작성하고, 포트 번호는 클라이언트 실제 설정과 일치시킵니다.
- Git 등 자체 프록시 설정 항목을 가진 도구는 별도로 확인해, 이미 만료된 예전 주소를 읽어들이지 않도록 합니다.
위 항목을 모두 확인했는데도 몇몇 애플리케이션이 시스템 프록시 설정이나 환경 변수를 전혀 인식하지 않는 경우가 있습니다. 흔히 있는 일인데, 일부 독립 프로세스 프로그램은 시스템 프록시 패널을 아예 검사하지 않고 셸 환경 변수도 읽지 않으며, 자체적으로 고정된 직접 연결 로직만 따릅니다. 이렇게 "말을 안 듣는" 애플리케이션을 만났다면 TUN 모드로 전환하는 게 더 효율적입니다. 클라이언트가 시스템 네트워크 계층에 가상 네트워크 어댑터를 만들어 모든 아웃바운드 트래픽을 네트워크 계층에서 통합 처리하므로, 개별 애플리케이션이 시스템 프록시 설정에 "협조"하는지 여부와 무관하게 브라우저, 터미널, 기타 독립 프로세스의 트래픽까지 한꺼번에 처리됩니다. TUN 모드는 처리 범위가 훨씬 넓지만 DNS 처리와 네트워크 어댑터 권한에 대한 요구도 더 높고, 설정할 때 시스템 프록시보다 권한 승인 단계가 하나 더 필요합니다. 구체적인 활성화 방법은 튜토리얼 페이지에서 플랫폼별 절차를 확인하세요.