macOS Clash 클라이언트 권한 설정: 네트워크 확장 승인 및 키체인 암호 팝업 해결
터미널에서 Claude Code를 실행할 때 요청이 시간 초과되거나 연결이 끊긴다면 프록시 경로부터 확인해 보세요. Clash Verge에 설정 파일을 불러오고 적절한 노드를 고른 뒤, Claude Code 트래픽에 규칙을 적용하는 방법을 안내합니다. 터미널 프록시 환경 변수와 자…
먼저 Claude Code 요청이 Clash Verge를 통과하는지 확인하세요
Claude Code를 터미널에서 실행할 때 웹 브라우저가 정상적으로 열려도 Claude Code의 요청까지 같은 경로를 사용한다고 단정할 수는 없습니다. 브라우저는 운영체제의 시스템 프록시를 따를 수 있지만, 터미널에서 실행한 프로그램은 별도의 프록시 환경 변수가 없으면 직접 연결을 시도할 수 있습니다. 따라서 Clash Verge 화면에 연결됨으로 표시되거나 브라우저에서 사이트가 열린다는 사실만으로 터미널의 API 연결 상태를 판단하기 어렵습니다.
요청 경로는 대략 다음처럼 나뉩니다. Claude Code가 터미널 환경을 읽고, 설정된 로컬 프록시 포트로 요청을 보내거나 운영체제의 네트워크 경로를 사용합니다. 이후 mihomo 코어가 연결을 받아 규칙과 정책 그룹을 적용하고, 선택된 노드를 통해 목적지에 연결합니다. 터미널 환경 변수, 로컬 포트, 규칙 또는 노드 중 하나라도 맞지 않으면 인증이나 응답을 받기 전에 시간 초과가 발생할 수 있습니다.
| 증상 | 우선 확인할 항목 | 비교 방법 |
|---|---|---|
| 브라우저는 열리지만 Claude Code가 시간 초과됨 | 터미널의 프록시 환경 변수 | 같은 터미널에서 변수와 프록시 지정 curl 결과 확인 |
| 프록시 연결 거부 또는 연결할 수 없음 | Clash Verge의 코어 상태와 로컬 포트 | 설정에 표시된 포트와 명령의 포트 비교 |
| 요청은 보이지만 연결이 실패함 | 규칙에 일치한 정책과 선택된 노드 | Clash Verge의 연결 목록에서 목적지와 경로 확인 |
| 로그인 또는 인증 단계에서 실패함 | 인증 상태, 시스템 시간, 관련 도메인 요청 | 네트워크 오류와 인증 오류를 구분해 기록 |
프로필, 코어, 로컬 프록시 포트를 확인하세요
먼저 Clash Verge에서 사용할 프로필이 선택되어 있고 설정 검사에 실패하지 않았는지 확인합니다. 프로필을 최근에 바꿨다면 업데이트 또는 다시 불러오기를 실행한 뒤, mihomo 코어가 실제로 실행 중인지 살펴보세요. 구독 노드 목록이 보인다는 사실만으로 코어가 정상 실행 중이라는 뜻은 아닙니다. 로그에 설정 파싱 오류나 포트 바인딩 오류가 있는지도 확인하세요.
그다음 설정 또는 포트 화면에서 HTTP, SOCKS, 혼합 포트의 실제 값을 확인합니다. 아래 예시의 7890은 자주 쓰이는 값일 뿐이며, 사용 중인 Clash Verge 설정과 일치하지 않으면 그대로 복사하면 안 됩니다. mixed-port는 보통 HTTP와 SOCKS 요청을 모두 받습니다. HTTP용 포트와 SOCKS용 포트를 별도로 설정했다면 Claude Code에 지정할 프로토콜에 맞는 포트를 사용하세요.
# 예시일 뿐이며 현재 프로필의 실제 포트와 비교하세요
mixed-port: 7890
allow-lan: false
mode: ruleClash Verge가 실행 중이어도 다른 프로그램이 같은 포트를 먼저 사용해 코어가 리스닝하지 못할 수 있습니다. Windows PowerShell에서는 다음 명령으로 예시 포트를 확인할 수 있습니다. macOS나 Linux에서는 lsof가 설치되어 있다면 두 번째 명령을 사용할 수 있습니다.
# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen
# macOS 또는 lsof가 설치된 Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN결과가 없다면 포트 번호가 바뀌었는지, 코어가 시작됐는지, 포트를 다른 클라이언트가 점유했는지 확인하세요. 이미 리스닝 중인 포트가 있더라도 해당 프로세스가 현재 사용 중인 Clash Verge인지 확인해야 합니다. 원인을 모르는 프로세스를 바로 종료하지 말고, 먼저 클라이언트 로그와 실행 중인 앱을 대조하세요.
규칙 모드와 노드 선택을 따로 점검하세요
규칙 모드에서는 터미널 요청이 Clash로 들어온 뒤 설정의 규칙 순서에 따라 처리됩니다. 예를 들어 api.anthropic.com 요청이 프록시 정책에 걸리는지, 해당 정책 그룹에서 실제로 사용할 수 있는 노드를 선택했는지 확인하세요. 인증 흐름에서는 Claude Code가 다른 관련 도메인에도 연결할 수 있으므로, 하나의 요청만 확인하고 전체 연결이 해결됐다고 단정하지 마세요. 실제 목적지는 Clash Verge의 연결 화면과 로그를 기준으로 확인합니다.
연결 목록에서 목적지 도메인, 일치한 규칙, 선택된 정책이나 노드를 확인하세요. 요청이 목록에 전혀 나타나지 않으면 터미널이 프록시 포트에 연결하지 않았거나 요청이 다른 네트워크 경로로 나갔을 수 있습니다. 연결은 보이는데 실패한다면 노드 상태, 정책 그룹에서 선택한 항목, 해당 목적지에 적용된 규칙을 차례로 살펴보세요. 지연 시간 테스트가 성공하더라도 특정 API 연결이 정상이라는 보장은 없습니다.
시스템 프록시와 TUN은 처리 대상이 서로 다릅니다. 시스템 프록시는 이를 따르는 앱에 프록시 주소를 알리는 방식이고, TUN은 운영체제의 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리할 수 있습니다. 하지만 TUN을 켰다고 모든 앱의 요청이 같은 규칙과 노드를 거치는 것은 아닙니다. 앱 제외 설정이나 라우팅 규칙, 권한 문제도 결과에 영향을 줄 수 있습니다.
문제 원인을 좁힐 때는 먼저 현재 설정을 기록한 뒤, 잠깐 전역 모드로 바꿔 정상 작동이 확인된 노드를 선택해 비교할 수 있습니다. 전역 모드에서만 요청이 성공한다면 규칙 모드에서 일치한 규칙이나 정책 그룹을 더 자세히 조사하세요. 이 비교를 위해 규칙 전체를 삭제하거나 TUN과 시스템 프록시를 한꺼번에 바꾸지는 마세요. 한 번에 한 항목만 조정하고 테스트 후 원래 모드로 돌려놓는 것이 안전합니다.
터미널 환경 변수를 설정해 직접 연결을 비교하세요
여기서는 로컬 혼합 포트가 7890인 경우를 예로 듭니다. 먼저 Clash Verge에서 확인한 포트가 실제로 7890인지 대조하세요. HTTP 프록시 주소는 원격 노드 주소가 아니라 같은 컴퓨터에서 실행 중인 로컬 프록시를 가리킵니다. 아래 설정은 현재 터미널 세션에만 적용되므로 터미널을 닫으면 사라집니다. 실제 주소와 포트가 다르면 두 환경 변수의 값을 함께 바꾸세요.
Windows PowerShell에서 설정하기
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"
# 변수가 설정됐는지 확인
Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:NO_PROXY그 상태에서 같은 창에서 Claude Code를 실행해야 환경 변수가 전달됩니다. 시작 메뉴나 다른 터미널에서 실행한 프로그램은 이 PowerShell 세션의 값을 자동으로 이어받지 않습니다. Windows에서는 별칭과 동작 차이를 피하기 위해 네트워크 테스트에 curl.exe를 사용하세요.
macOS 또는 Linux 셸에서 설정하기
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|no)_proxy='NO_PROXY에는 로컬 주소만 넣는 것이 일반적입니다. 여기에 접속하려는 API 도메인을 넣으면 해당 요청은 프록시를 우회할 수 있습니다. 환경 변수를 영구 적용하려면 사용 중인 셸에 따라 ~/.zshrc 또는 ~/.bashrc에 추가할 수 있지만, 먼저 위처럼 임시 설정으로 확인하세요. 공유 컴퓨터에서 환경 변수에 프록시 인증 정보를 직접 적어 두는 것은 피하는 편이 좋습니다.
이제 같은 터미널에서 프록시를 지정한 요청을 시험합니다. Windows에서는 아래 명령의 curl을 curl.exe로 바꾸세요.
curl -v --proxy http://127.0.0.1:7890 https://api.anthropic.com/출력에 프록시 연결과 TLS 핸드셰이크가 나타나고 HTTP 응답 코드까지 도달한다면 로컬 포트와 원격 연결 경로를 확인하는 데 도움이 됩니다. 테스트 주소에서 401이나 404 같은 응답이 나올 수 있습니다. 이 결과만으로 Claude Code 인증이 성공했다고 볼 수는 없지만, 연결 시간 초과와 HTTP 응답은 구분할 수 있습니다. TLS 인증서 검증 오류가 나면 시스템 시간, 네트워크 검사 장치, 인증서 관련 설정을 확인하세요. 인증서 검증을 끄는 옵션으로 우회하지 마세요.
테스트 결과와 Clash Verge의 연결 목록을 같은 시각에 비교합니다. 요청이 목록에 나타나지 않으면 환경 변수가 현재 터미널 프로세스에 적용됐는지, 다른 셸이나 실행기가 변수를 덮어쓰지 않았는지 확인하세요. 목록에 나타나지만 연결이 실패한다면 해당 요청에 적용된 규칙과 노드를 점검합니다. 직접 지정한 curl은 성공하지만 Claude Code만 실패한다면 실행한 터미널, Claude Code 버전, 로그인 상태와 오류 로그를 별도로 비교하세요.
같은 터미널에서 실행하고 변경 사항을 정리하세요
프록시 환경 변수를 설정한 터미널에서 Claude Code를 실행한 뒤, 짧은 요청을 한 번 보내고 오류 메시지와 연결 목록을 대조합니다. 브라우저에서 Claude 서비스를 열어 둔 상태만으로는 이 테스트를 대신할 수 없습니다. 데스크톱 바로가기, IDE 내장 터미널, 원격 개발 터미널은 각각 다른 환경 변수를 받을 수 있으므로, 성공한 터미널과 실제로 사용하려는 실행 환경이 같은지 확인하세요.
인증 오류가 표시되면 프록시 연결 자체가 아니라 로그인 세션, 계정 권한, 시스템 시각 문제일 수도 있습니다. 네트워크 시간 초과와 인증 실패를 구분하고, 같은 오류가 반복될 때는 요청 시각과 Claude Code가 출력한 오류를 기록하세요. 오류 로그나 화면 캡처를 공개할 때 API 키, 인증 헤더, 세션 토큰, 구독 주소가 포함되지 않았는지 반드시 확인합니다.
- PowerShell: 테스트를 마친 뒤 현재 세션에서
Remove-Item Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:NO_PROXY를 실행하면 임시 변수를 제거할 수 있습니다. - macOS 또는 Linux: 현재 셸에서
unset HTTP_PROXY HTTPS_PROXY NO_PROXY를 실행하면 임시 변수를 제거할 수 있습니다. - 영구 설정을 추가한 경우: 셸 설정 파일에서 해당 줄을 제거하거나 주석 처리하고 새 터미널을 열어 이전 값이 남아 있지 않은지 확인하세요.
- Clash Verge 설정을 바꾼 경우: 비교가 끝나면 원래 규칙 모드, 시스템 프록시, TUN 상태로 되돌리고 정상적인 브라우저 연결도 다시 확인하세요.
마지막으로 환경 변수를 설정했는데도 Claude Code가 프록시를 사용하지 않는다면, 실행 프로세스가 그 변수를 실제로 상속했는지부터 확인하세요. 반대로 요청이 Clash Verge에 도달하지만 응답이 오지 않는다면 포트 변경, 규칙 분기, 정책 그룹의 노드 선택을 다시 살펴보면 됩니다. 이렇게 터미널 환경, 로컬 수신 포트, 트래픽 경로를 나누어 점검하면 시스템 전체 설정을 불필요하게 바꾸지 않고 원인을 좁힐 수 있습니다.