문제 해결 예상 읽기 시간 10분

macOS Clash 시스템 프록시가 작동하지 않을 때: 브라우저와 터미널별 해결 방법

Safari와 Chrome은 시스템 프록시를 사용하지만 터미널은 기본적으로 사용하지 않습니다. 네트워크 설정의 프록시 항목을 확인하고 셸에 http_proxy 환경 변수를 설정하는 방법을 안내합니다.

시스템 프록시, 터미널 프록시, TUN 구분하기

Clash 클라이언트에 ‘시스템 프록시가 켜짐’으로 표시되면 클라이언트가 macOS 프록시 설정을 변경하려고 했다는 뜻입니다. 모든 앱의 트래픽이 프록시를 통과한다는 의미는 아닙니다. Safari는 대체로 시스템 프록시를 사용하며 Chrome도 기본적으로 시스템 프록시를 참조하지만, 확장 프로그램이나 실행 옵션, 조직 정책에 따라 동작이 달라질 수 있습니다. 터미널에서 실행하는 명령줄 프로그램은 각자 프록시를 설정하는 방식이 다르므로 브라우저에서 웹사이트가 열리는지만으로 판단할 수 없습니다.

그래픽 클라이언트는 설정 가져오기, 정책 그룹 전환, 시스템 설정 관리를 담당하고, 코어는 프록시 포트를 열어 규칙에 따라 요청을 전달합니다. 클라이언트 화면이 실행 중이어도 설정 오류로 코어가 시작되지 않았을 수 있습니다. 문제를 해결할 때는 ‘프록시 설정이 적용되었는지’와 ‘로컬 포트에 실제로 연결할 수 있는지’를 각각 확인해야 합니다.

연결 방식주요 확인 위치적용 범위
시스템 프록시현재 macOS 네트워크 서비스의 프록시 항목앱이 해당 설정을 사용해야 적용됩니다
터미널 프록시 직접 설정명령 옵션, 환경 변수, 도구별 설정일반적으로 지정한 프로세스와 하위 프로세스에만 적용됩니다
TUN 모드가상 네트워크 인터페이스, 라우팅, DNS, 권한클라이언트와 코어의 지원이 필요하며 별도의 연결 방식입니다

코어 실행 여부와 로컬 수신 포트 확인

구독 파일이 아닌 실행 설정 확인

먼저 클라이언트에서 현재 설정이 정상적으로 적용되었는지, HTTP·SOCKS·혼합 포트가 각각 몇 번인지 확인하세요. 클라이언트마다 화면의 메뉴 이름과 설정 덮어쓰기 방식이 다르므로 동일한 메뉴 경로를 일괄 적용할 수 없습니다. 클라이언트 설정이 구독 파일의 포트 값을 덮어쓸 수도 있으니 실행 설정과 시작 로그를 우선 확인하세요.

혼합 포트를 지원하는 코어는 하나의 포트로 HTTP와 SOCKS 요청을 모두 받을 수 있습니다. 아래는 일부 설정 항목만 보여 주는 예시입니다. 노드와 정책 그룹이 포함된 전체 구독 파일이 아니며, 문제를 해결하기 위해 원본 파일을 덮어쓸 필요도 없습니다.

mixed-port: 7890
allow-lan: false
mode: rule

allow-lan: false여도 로컬에서 127.0.0.1을 사용할 수 있습니다. 현재 Mac만 점검한다면 시스템 프록시를 작동시키기 위해 로컬 네트워크 접근을 허용할 필요가 없습니다. TCP 수신 상태는 다음 명령으로 확인할 수 있습니다.

lsof -nP -iTCP:7890 -sTCP:LISTEN
  • 수신 항목이 있으면 해당 프로세스가 사용하려는 클라이언트 또는 그 코어인지 확인하고, 수신 주소가 로컬 루프백 연결을 허용하는지 확인하세요.
  • 항목이 없으면 포트 번호가 맞는지, 코어 시작에 실패했는지, 설정 로그에 구문 분석 오류가 있는지 확인하세요. 필요한 경우 관리자 권한으로 프로세스가 표시되는지도 다시 확인합니다.
  • 다른 프로그램이 포트를 사용 중이면 먼저 충돌을 해결한 다음 클라이언트의 수신 포트와 시스템 프록시 포트를 함께 변경하세요. 한쪽만 바꾸지 마세요.

시스템 설정을 거치지 않고 프록시 연결 직접 확인

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

이 명령은 지정한 HTTP 프록시를 통해 HTTPS 주소에 접속합니다. --noproxy ""는 현재 우회 목록의 영향을 제외합니다. example.com은 연결 테스트용 주소이므로 실제 문제가 발생한 웹사이트로 바꿔 다시 테스트하세요. 응답 상태 코드가 반드시 200일 필요는 없습니다. 로컬 연결 실패, 프록시 터널 연결 실패, TLS 오류, 원격 서버의 HTTP 응답을 구분하는 것이 핵심입니다.

127.0.0.1:7890에 연결할 수 없다는 메시지가 나오면 먼저 로컬 포트를 확인하세요. 로컬 프록시에는 연결됐지만 시간이 초과되면 클라이언트 연결 기록과 규칙 적용 결과, 노드 로그를 살펴보세요. 직접 지정한 프록시로는 접속되는데 브라우저에서만 실패할 때 macOS 프록시 설정 적용 경로를 점검하는 것이 좋습니다.

브라우저에서 프록시가 작동하지 않을 때: 현재 네트워크 서비스의 프록시 설정 확인

사용 중인 Wi-Fi 또는 이더넷 서비스 확인

‘시스템 설정’ 화면을 사용하는 macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 사용 중인 네트워크 서비스 → ‘세부사항’ → ‘프록시’로 이동합니다. Wi-Fi는 ‘시스템 설정’ → ‘Wi-Fi’ → 현재 네트워크의 ‘세부사항’에서도 확인할 수 있습니다. 이전 버전의 시스템 환경설정에서는 보통 ‘네트워크’ → 현재 서비스 → ‘고급’ → ‘프록시’에 있습니다. 실제 Mac에 표시되는 메뉴를 기준으로 확인하세요.

‘웹 프록시(HTTP)’와 ‘보안 웹 프록시(HTTPS)’를 확인하세요. 서버는 127.0.0.1로, 포트는 클라이언트의 HTTP 포트 또는 혼합 포트와 동일하게 설정해야 합니다. 여기서 HTTPS 프록시 설정은 HTTPS 사이트 요청에 사용할 프록시를 지정하는 것입니다. 로컬 프록시 주소를 https://127.0.0.1로 입력해야 한다는 뜻은 아닙니다.

macOS 프록시 설정은 네트워크 서비스별로 저장됩니다. Wi-Fi에서 USB 이더넷으로 전환했다면 이전 서비스에 설정이 올바르게 되어 있어도 새 서비스의 설정은 다를 수 있습니다. 먼저 서비스를 확인한 다음 현재 사용 중인 서비스의 설정을 조회하세요.

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getproxybypassdomains "Wi-Fi"
networksetup -getautoproxyurl "Wi-Fi"
networksetup -getproxyautodiscovery "Wi-Fi"

서비스 이름이 Wi-Fi가 아니라면 첫 번째 명령의 결과에 표시된 실제 이름으로 바꾸고 따옴표는 그대로 유지하세요. 아래는 예상되는 설정 항목의 예시이지 실제 Mac에서 확인한 결과가 아닙니다. HTTP와 HTTPS 항목을 각각 확인해야 합니다.

Enabled: Yes
Server: 127.0.0.1
Port: 7890
Authenticated Proxy Enabled: 0

PAC, 우회 목록, 브라우저별 설정 확인

  • 자동 프록시 구성:PAC 스크립트는 대상에 따라 프록시 사용 여부를 결정할 수 있습니다. 기존 값을 기록한 뒤 테스트 중에는 프록시 방식을 하나만 남겨 PAC의 분기 결과를 수동 프록시 오류로 오인하지 않도록 하세요.
  • 우회 목록:localhost, 127.0.0.1, *.local은 로컬 접속에 자주 사용됩니다. 대상 도메인이나 지나치게 넓은 와일드카드 규칙이 잘못 추가되어 있는지 확인하세요. 모든 로컬 우회 항목을 지울 필요는 없습니다.
  • 브라우저 확장 프로그램:Chrome에서 프록시 전환 확장 프로그램을 일시 중지한 뒤 다시 테스트하세요. 조직에서 관리하는 기기라면 정책도 확인해야 하며, 관리되는 설정을 임의로 덮어쓰면 안 됩니다.
  • 여러 클라이언트:두 프록시 도구가 동시에 시스템 설정을 변경하지 않도록 하세요. 설정이 이전 포트로 계속 돌아간다면 어떤 프로세스가 아직 설정을 관리하는지 먼저 확인하세요.

설정을 변경한 뒤 웹페이지를 다시 요청하고, 필요하면 브라우저를 완전히 종료했다가 다시 여세요. 결과가 캐시에 영향을 받지 않도록 이전에 열지 않은 페이지를 테스트하는 것이 좋습니다. 동시에 클라이언트 연결 기록도 확인하세요. 새 연결이 전혀 없다면 앱의 요청이 프록시로 전달되지 않았을 가능성이 큽니다. 연결은 기록되지만 규칙에 따라 DIRECT로 전송된다면 규칙 선택 문제입니다.

브라우저는 되지만 터미널은 안 될 때: 셸 프록시 변수 설정

터미널에서 실행하는 curl, Git, 패키지 관리자는 macOS 시스템 프록시를 모두 동일하게 따르지 않습니다. 일부 도구는 환경 변수를 읽고, 일부는 자체 설정을 사용하며, 또 다른 도구는 시스템 네트워크 API를 이용합니다. 먼저 단일 명령으로 테스트한 다음 셸 전체에 설정할지 결정하세요.

명령 하나에만 프록시 설정해 테스트

http_proxy=http://127.0.0.1:7890 \
https_proxy=http://127.0.0.1:7890 \
curl -I --connect-timeout 10 --max-time 20 https://example.com/

여기서 https_proxy 값이 http://로 시작하는 이유는 로컬 프록시가 HTTP 방식으로 연결을 받기 때문입니다. HTTPS 사이트에 접속할 때 도구는 보통 HTTP CONNECT로 터널을 만듭니다. 대상이 HTTPS라는 이유만으로 변수 값을 TLS 프록시 주소로 바꾸지 마세요.

현재 터미널 세션에 변수 내보내기

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"

env | grep -iE '^(http|https|all|no)_proxy='
curl -I --connect-timeout 10 --max-time 20 https://example.com/

이렇게 내보낸 변수는 현재 셸과 이후 실행되는 하위 프로세스에만 적용됩니다. 이미 열려 있는 다른 터미널 창이나 Dock에서 실행하는 모든 그래픽 앱의 설정을 자동으로 바꾸지는 않습니다. 도구마다 환경 변수의 대소문자 지원이 다릅니다. 예를 들어 curl은 HTTP 프록시 변수로 소문자 http_proxy를 사용하므로 대문자 HTTP_PROXY만 설정해서는 안 됩니다.

SOCKS 연결을 사용하는 경우 아래 명령으로 별도 테스트할 수 있습니다. 해당 포트가 실제로 SOCKS를 지원할 때만 사용하세요. 이 예시의 혼합 포트는 두 요청 방식을 모두 지원합니다. socks5h는 대상 호스트 이름을 프록시에서 해석하게 하므로 로컬 DNS 문제와 프록시 경로 문제를 구분하는 데 도움이 됩니다.

curl -I --noproxy "" \
  --proxy socks5h://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  https://example.com/

영구 설정 전에 기존 변수 확인

임시 테스트가 통과한 뒤 대화형 zsh를 사용한다면 필요한 export 행을 ~/.zshrc에 추가하고 새 터미널 창을 열거나 source ~/.zshrc를 실행하세요. 다른 셸에서는 해당 셸의 시작 파일을 사용해야 합니다. 클라이언트를 종료해도 변수는 로컬 포트를 가리키므로, 필요할 때만 켜는 방식이 계속 설정해 두는 것보다 문제를 해결하기 쉽습니다.

# 현재 셸의 일반적인 프록시 변수 해제
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

시작 파일에 변수를 추가했다면 해당 행도 삭제하거나 주석 처리해야 새 터미널 창에서 다시 불러오지 않습니다. all_proxy가 이전 포트를 가리키는지, no_proxy에 대상 도메인이 포함되어 있는지도 확인하세요. 프로그램마다 변수 우선순위와 일치 규칙이 다를 수 있으므로 여러 종류의 프록시 변수를 한꺼번에 설정하지 않는 것이 좋습니다.

Git 또는 패키지 관리자만 실패할 때: 도구별 프록시 설정 확인

같은 터미널에서 curl은 작동하는데 Git만 실패한다면 시스템 프록시를 계속 바꾸지 말고 Git 설정 출처를 확인하세요. 오래된 전역 프록시, 저장소별 프록시, URL별 프록시 설정 때문에 Git이 다른 경로를 사용할 수 있습니다.

git config --show-origin --get-regexp '.*proxy.*'

# 이번 HTTPS 저장소 접속에만 프록시 지정
git -c http.proxy=http://127.0.0.1:7890 \
  ls-remote https://github.com/git/git.git HEAD

두 번째 명령은 공개 저장소에 접속해 보는 테스트이며 전역 설정을 변경하지 않습니다. 조회 결과에 계정, 비밀번호 또는 비공개 주소가 포함되어 있다면 로그를 공유하기 전에 가리세요. 전역 http.proxy 설정이 잘못된 것으로 확인된 경우에만 git config --global --unset http.proxy를 사용하세요. 저장소별 설정과 URL 전용 설정은 해당 범위에서 처리해야 합니다.

  • HTTPS 주소를 사용하는 Git 요청과 git@호스트:저장소 형식의 SSH 요청은 서로 다른 프로토콜 경로입니다. HTTP 프록시 테스트 결과만으로 SSH 연결 여부를 판단할 수 없습니다.
  • npm config get proxy와 npm config get https-proxy 명령으로 npm의 개별 설정을 확인할 수 있습니다. 변경하기 전에 기존 값을 기록해 두세요.
  • sudo를 사용하면 환경 변수가 제거될 수 있습니다. 프록시 변수를 전달하려고 모든 환경 변수를 그대로 유지하지 말고 해당 도구에 필요한 최소 설정을 확인하세요.

요청이 Clash에 도달했을 때: 규칙, DNS, TUN 확인

연결 기록에 대상 요청이 나타나면 적어도 해당 요청은 코어에 도달한 것입니다. 이 경우 ‘시스템 프록시가 작동하지 않는다’는 설명이 정확하지 않을 수 있으므로 적용된 규칙, 현재 선택된 정책 그룹, 최종 연결 경로를 확인하세요. 규칙 모드는 설정 순서에 따라 일치 항목을 찾으며, 마지막의 MATCH는 앞선 규칙에 일치하지 않은 요청에만 적용됩니다. 정책 그룹을 선택했더라도 현재 구성원이 반드시 프록시 노드라는 보장은 없습니다.

  1. 규칙에 따른 연결 경로:대상 도메인에 일치한 규칙과 최종 경로가 노드, DIRECT, REJECT 중 무엇인지 기록하세요. 직접 연결 규칙이 설정되어 있으면 요청이 코어를 거친 뒤에도 직접 연결될 수 있습니다.
  2. 노드와 회선:같은 대상에 다른 정상 노드를 선택해 다시 테스트하세요. 클라이언트의 지연 시간 테스트는 테스트 주소에 대한 결과일 뿐, 대상 웹사이트에 실제로 연결되는지를 대신 확인해 주지는 않습니다.
  3. DNS:로컬에서 이름 해석에 실패한 경우, 코어의 상위 DNS 조회에 실패한 경우, 원격 연결에 실패한 경우를 구분하세요. fake-ip를 켜는 것이 만능 해결책은 아닙니다. DNS 가로채기와 앱 호환성도 함께 고려해야 합니다.
  4. TUN:명시적 프록시를 따르지 않는 앱의 트래픽까지 처리해야 할 때만 클라이언트 지원 여부, 권한, 라우팅, DNS 설정을 확인하세요. mihomo 기반 클라이언트라도 TUN 설정 항목은 서로 다를 수 있으므로 다른 클라이언트의 메뉴 경로를 그대로 적용하지 마세요.

재테스트 순서와 종료 후 복원

설정을 조정한 뒤 아래 순서대로 확인하세요. 브라우저와 터미널 테스트가 각각 성공해야 두 연결 경로가 모두 올바르게 설정된 것입니다. 웹페이지 하나가 열린다고 해서 모든 앱이 프록시를 사용한다는 뜻은 아닙니다.

  1. lsof로 실제 포트가 수신 대기 중인지 확인합니다.
  2. curl --proxy로 프록시를 지정해 테스트하고 로컬 연결과 대상 사이트 접속이 모두 되는지 확인합니다.
  3. 현재 네트워크 서비스의 HTTP 및 HTTPS 프록시 항목을 확인한 다음 브라우저에서 대상 페이지를 다시 요청합니다.
  4. 터미널 변수와 도구별 프록시 설정을 확인하고 같은 터미널에서 curl과 실제 작업 명령을 각각 테스트합니다.
  5. 클라이언트를 종료하기 전에 시스템 프록시 관리를 해제하세요. 종료 후 네트워크 설정을 다시 확인해 프록시가 더 이상 수신하지 않는 포트를 가리키지 않도록 합니다.

클라이언트가 비정상 종료된 뒤 모든 웹페이지에 접속할 수 없다면 현재 네트워크 서비스의 ‘프록시’ 페이지를 열어 남아 있는 로컬 수동 프록시 설정을 기록하고 끄세요. 그런 다음 터미널 변수를 해제하고 직접 연결을 테스트합니다. 조직에서 관리하는 프록시와 PAC 설정은 관리 정책에 따라 복원하고 함께 삭제하지 마세요. 원인을 더 확인해야 한다면 실제 포트, 서비스 이름, 명시적 프록시 테스트에서 오류가 발생한 단계, 개인정보를 가린 연결 로그를 정리하세요. ‘프록시가 반응하지 않는다’고만 설명하는 것보다 문제 파악에 도움이 됩니다.

포트와 규칙 항목은 YAML 설명서에서, 설정 가져오기와 TUN의 플랫폼별 사용법은 사용 가이드에서 확인할 수 있습니다. 문제 해결의 핵심은 앱의 연결 경로, 로컬 코어, 원격 연결 경로를 각각 나눠 점검하는 것입니다.

Clash 다운로드