브라우저는 되는데 Claude Code 터미널만 연결되지 않는 이유
Clash Verge에서 시스템 프록시를 켰는데도 Claude Code가 연결되지 않는다면, 먼저 브라우저와 터미널이 같은 프록시 설정을 사용한다고 가정하지 않는 것이 좋습니다. 브라우저는 운영체제의 시스템 프록시를 자동으로 따르는 경우가 많지만, 셸에서 실행한 Node.js 기반 CLI는 별도의 프록시 환경 변수가 없으면 그 설정을 사용하지 않을 수 있습니다. 따라서 웹에서 Claude 페이지가 열리는 것만으로는 Claude Code의 API 연결까지 확인했다고 보기 어렵습니다.
또 다른 흔한 원인은 프록시 포트 착오입니다. Clash Verge의 혼합 포트는 설치 상태나 사용자가 바꾼 설정에 따라 달라질 수 있으므로, 익숙한 포트 번호를 그대로 복사하기보다 앱의 포트 설정에서 실제 값을 확인해야 합니다. 포트가 맞더라도 연결 모드가 전역 또는 규칙으로 설정되어 있는지, 코어가 실행 중인지, 선택한 프로필이 활성 상태인지 함께 살펴보세요. 화면에서 프록시 노드를 선택한 것과 터미널 요청이 그 노드를 통과하는 것은 서로 다른 단계입니다.
문제를 빠르게 좁히려면 Claude Code 실행 직후 Clash Verge의 연결 로그를 열어 새로 생긴 요청을 확인합니다. 요청이 전혀 보이지 않으면 터미널이 프록시 포트에 도달하지 못했거나 환경 변수가 전달되지 않은 가능성이 큽니다. 요청은 보이지만 연결이 실패한다면 매칭된 규칙, 선택된 정책 그룹, DNS 또는 원격 API 응답을 차례로 확인합니다. 연결 로그를 읽는 방법은 연결 로그·TLS 점검 가이드도 참고할 수 있습니다.
Clash Verge에서 포트와 프록시 모드 확인하기
설정을 바꾸기 전에 현재 활성 프로필을 확인합니다. 구독 프로필을 여러 개 사용하는 경우 다른 프로필을 편집하고 있을 수 있습니다. Clash Verge에서 활성 프로필을 선택하고 코어가 정상적으로 실행 중인지 확인한 다음, 설정 화면에서 혼합 포트 또는 HTTP·SOCKS 포트 값을 확인하세요. 메뉴 이름은 버전에 따라 조금 다를 수 있으므로, 표시된 설정 항목과 연결 로그를 기준으로 판단하는 편이 안전합니다.
환경 변수에 사용할 주소는 대개 로컬 컴퓨터의 루프백 주소와 Clash Verge의 실제 포트를 조합합니다. 예를 들어 혼합 포트가 7897로 표시되어 있다면 127.0.0.1:7897처럼 지정할 수 있습니다. 이 번호는 설명용 예시일 뿐이며, 자신의 설정과 다르면 반드시 앱에 표시된 값을 사용해야 합니다. SOCKS 포트만 따로 지정된 환경에서는 그 포트를 사용할 수 있지만, 먼저 HTTP 요청까지 받을 수 있는 혼합 포트로 시험하면 설정을 단순하게 검증하기 좋습니다.
프록시 모드도 확인해야 합니다. 규칙 모드에서는 요청한 도메인이 어떤 규칙에 걸리는지에 따라 프록시 또는 직접 연결로 나뉩니다. 전역 모드는 진단 과정에서 비교 기준으로 유용할 수 있지만, 모든 트래픽을 같은 경로로 보내므로 회사 내부 서비스나 지역 서비스에 영향을 줄 수 있습니다. 진단을 위해 모드를 바꿨다면 테스트가 끝난 뒤 원래 운영 방식으로 되돌리고, 업무 네트워크의 정책을 우선하세요.
규칙 모드에서 Claude Code 요청이 직접 연결되는 것으로 보인다면, 연결 로그에서 실제 대상 호스트와 선택된 정책을 기록합니다. 도메인 이름을 추측해 넓은 규칙을 추가하기보다는, 실패한 요청에 나타난 호스트가 무엇인지 확인한 뒤 필요한 범위만 조정하세요. 구독 규칙과 직접 작성한 규칙의 순서가 복잡한 경우에는 규칙 라우팅 원칙을 함께 살펴보면 원치 않는 매칭을 줄이는 데 도움이 됩니다.
셸에 프록시 환경 변수 적용하기
Clash Verge의 시스템 프록시 설정만으로 터미널 앱이 자동 연결되지 않는다면, Claude Code를 실행하는 셸에 프록시 환경 변수를 지정합니다. macOS와 Linux의 Bash·Zsh에서는 현재 터미널 창에서 아래처럼 입력할 수 있습니다. 포트 번호는 앞에서 확인한 값으로 바꾸세요.
export HTTP_PROXY="http://127.0.0.1:7897"
export HTTPS_PROXY="http://127.0.0.1:7897"
export ALL_PROXY="http://127.0.0.1:7897"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"대소문자 환경 변수 지원은 프로그램과 라이브러리에 따라 차이가 있을 수 있어, 진단할 때는 대문자와 소문자 변수를 함께 설정하는 편이 호환성 확인에 유리합니다. 다만 모든 변수를 영구 설정으로 추가하기 전에 현재 창에서 먼저 시험하세요. 임시 설정은 해당 터미널에서 시작한 프로세스에만 적용되므로, 변수를 바꾸고도 이미 실행 중인 Claude Code가 새 설정을 읽지 않는 문제를 피할 수 있습니다. 실행 중인 세션을 종료하고 새로 시작해야 변경 내용이 전달됩니다.
연결이 확인된 후 설정을 계속 사용하려면 사용하는 셸에 맞는 시작 파일에 필요한 줄을 추가할 수 있습니다. Zsh는 보통 ~/.zshrc, Bash는 환경에 따라 ~/.bashrc 또는 ~/.bash_profile을 사용합니다. 파일을 수정한 뒤 새 터미널을 열거나 셸 설정을 다시 불러오세요. 여러 개발 환경에서 프록시를 번갈아 사용한다면 변수를 주석 처리하거나 별도 실행 스크립트로 관리하는 편이, 항상 프록시를 켜 두는 것보다 혼선을 줄여 줍니다.
Windows PowerShell에서는 현재 창에 다음과 같이 설정할 수 있습니다. 새 PowerShell 창을 열면 임시 설정은 사라집니다. 지속 설정을 적용하기 전에는 반드시 프록시 연결이 정상인지 확인하고, 필요하면 이전 환경 변수 값을 기록해 두세요.
$env:HTTP_PROXY = "http://127.0.0.1:7897"
$env:HTTPS_PROXY = "http://127.0.0.1:7897"
$env:ALL_PROXY = "http://127.0.0.1:7897"
내부 서비스나 로컬 콜백을 프록시 밖으로 보내야 하는 환경이라면 NO_PROXY도 점검합니다. 일반적으로 localhost와 127.0.0.1을 제외 대상으로 넣을 수 있지만, 회사에서 사용하는 내부 도메인 전체를 무심코 추가하면 해당 요청이 프록시를 우회할 수 있습니다. 꼭 필요한 주소만 포함하고, Claude Code의 인증 과정에서 브라우저가 열릴 경우 로그인 페이지와 로컬 콜백을 각각 확인하세요. CLI와 브라우저가 서로 다른 프록시 경로를 사용하면 인증이 완료되지 않거나 터미널로 돌아온 뒤 세션이 이어지지 않을 수 있습니다.
curl로 연결을 시험하고 원인을 분리하기
Claude Code를 바로 반복 실행하기보다, 같은 터미널에서 일반 HTTPS 요청을 먼저 시험하면 문제 범위를 좁히기 쉽습니다. 아래 명령은 응답 본문을 저장하지 않고 상태 코드와 연결에 걸린 시간을 표시합니다. API 호스트가 응답하더라도 인증되지 않은 요청에는 오류 상태가 반환될 수 있으므로, 이 테스트의 목적은 유효한 Claude 응답을 받는 것이 아니라 네트워크 연결이 성립하는지 확인하는 데 있습니다.
curl -sS -o /dev/null -w "HTTP %{http_code} / %{time_total}s\n" https://api.anthropic.com이 요청이 실패하면 Clash Verge 연결 로그에서 테스트 시각에 해당하는 연결이 보이는지 확인하세요. 로그에 요청이 없으면 변수 이름이나 값, 포트, 실행한 터미널 환경을 다시 점검합니다. 요청이 나타나지만 시간 초과가 발생한다면 현재 선택한 노드와 정책 그룹 상태를 확인하고, 다른 노드로 바꾼 뒤 같은 명령을 한 번 더 실행해 비교합니다. 반대로 요청이 빠르게 끝나는데 Claude Code만 실패한다면 API 인증, 앱 설정, 실행 환경이 서로 다른지 살펴볼 차례입니다.
셸에서 설정한 값이 실제 프로세스에 전달됐는지 확인하려면 환경 변수의 존재를 살펴봅니다. 출력에 자격 증명이나 민감한 값이 포함되지 않도록 주의하고, 터미널 로그나 공유 화면에 개인 토큰을 붙여 넣지 마세요. 디버깅을 위해 상세 연결 출력을 켤 때도 요청 헤더와 토큰을 공개하지 않는 것이 중요합니다. 연결 성공 후에는 필요한 경우 환경 변수 값을 확인하고, 실험을 위해 추가했던 임시 설정을 정리합니다.
자주 만나는 증상과 우선 점검 지점을 아래 표에 정리했습니다. 한 번에 여러 설정을 바꾸지 말고, 각 항목을 하나씩 바꾼 뒤 동일한 테스트를 반복해야 무엇이 영향을 줬는지 알 수 있습니다.
| 증상 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
| Clash 연결 로그에 요청이 없음 | 환경 변수, 포트 번호, 새 셸에서 실행했는지 여부 | 활성 셸에서 변수를 다시 설정하고 curl 테스트 |
| 로그에 요청은 있지만 시간 초과 | 규칙 매칭, 정책 그룹, 노드 연결 상태 | 로그의 정책을 확인하고 다른 노드와 비교 |
| curl은 응답하지만 Claude Code는 실패 | 인증 상태, CLI 실행 환경, API 관련 설정 | CLI를 새 셸에서 실행하고 로그인 상태 재확인 |
| 브라우저 로그인 후 터미널로 돌아오지 않음 | 브라우저와 CLI의 프록시 경로, 로컬 콜백 | loopback 제외 설정과 로그인 흐름을 점검 |
해결 후에는 셸을 새로 열어 환경 변수가 의도대로 적용되는지, Claude Code가 실제 요청을 보내는지, Clash 로그에서 해당 요청이 예상한 정책으로 처리되는지 각각 확인합니다. 터미널 전체 트래픽을 무조건 한 노드로 보내는 방식은 간단해 보여도 내부 도메인과 일반 다운로드까지 같은 경로에 묶을 수 있습니다. 가능하면 관측한 호스트와 필요한 정책을 기준으로 범위를 좁히고, 변경 내용을 기록해 다음 프로필 갱신 뒤에도 재현할 수 있도록 관리하세요.
일부 범용 프록시 앱은 시스템 프록시 버튼만 제공해 터미널 환경 변수나 규칙 로그를 따로 점검하기 어렵고, 오래된 클라이언트는 최신 코어 기능이나 프로필 관리가 제한될 수 있습니다. 반면 Clash Verge는 코어 상태와 연결 로그, 프록시 모드, 프로필을 한곳에서 살펴볼 수 있어 Claude Code의 셸 설정을 검증할 때 원인을 단계별로 추적하기 편리합니다. 터미널 프록시 설정을 마친 뒤에도 연결 문제가 반복된다면 Clash V.CORE를 내려받아 현재 환경과 비교해 보세요. 다운로드 페이지에서 시작할 수 있습니다.