1. 왜 브라우저는 되는데 터미널만 안 되나
macOS·Linux 데스크톱에서 Safari·Chrome 등은 운영체제나 브라우저 자체의 시스템 프록시 설정을 따르는 경우가 많습니다. 반면 curl·git·Node 패키지 매니저 같은 CLI는 기본적으로 그 설정을 자동으로 물려받지 않습니다. TUN 모드로 전체 트래픽을 가로채는 구성이라면 터미널도 같이 타는 경우가 있지만, “시스템 프록시만 켠 상태”·“일부 앱만 예외 처리”·“도구가 프록시 환경 변수를 무시하는 빌드”처럼 예외가 생기면 증상이 갈립니다.
따라서 개발자 입장에서는 로컬 루프백의 Clash 리스너 주소를 한 번 정하고, 그 주소를 환경 변수와 도구별 설정에 반복해서 넣는 패턴이 가장 예측 가능합니다. 전역 개념은 설정 문서로 잡고, 여기서는 “숫자 포트와 문자열 한 줄”을 맞추는 실무에 집중합니다.
curl -v --proxy http://127.0.0.1:포트 https://www.google.com/generate_204 한 줄로 프록시 경로가 살아 있는지 증명한 뒤, npm·Git 문제로 범위를 좁히면 원인 분리가 빨라집니다. 포트 번호는 본인 config.yaml·클라이언트 UI의 mixed-port와 반드시 일치해야 합니다.
2. Clash 쪽에서 먼저 확인할 것: mixed-port·수신 주소
Clash·Mihomo 계열은 보통 mixed-port 하나로 HTTP와 SOCKS를 함께 받거나, port·socks-port를 나눕니다. 터미널에서 http://127.0.0.1:7890 형태로 붙는 경우가 많으나, 프로필마다 다르므로 UI나 설정 파일에서 실제 숫자를 확인해야 합니다. GUI 클라이언트는 Allow LAN·바인드 주소 옵션에 따라 127.0.0.1에만 열리기도 하고 0.0.0.0에서 열리기도 합니다. 같은 기기의 터미널만 쓴다면 127.0.0.1로 충분한 경우가 대부분입니다.
Linux에서 코어를 systemd로만 돌리는 경우는 Ubuntu·Mihomo 설치 글의 순서로 포트가 열렸는지부터 확인하면 됩니다. macOS에서 Clash Verge 등을 쓸 때 시스템 확장·권한 이슈는 별도 글의 범위이고, 본문은 “프록시 포트가 로컬에서 응답한다”는 전제가 섰다고 가정합니다.
Allow LAN을 켜면 같은 네트워크의 다른 기기에서도 프록시 포트에 접근할 수 있습니다. 신뢰할 수 있는 가정·사무망에서만 사용하고, 공용 Wi‑Fi에서는 끄는 것이 안전합니다.
3. 셸 환경 변수: http_proxy·HTTPS_PROXY·ALL_PROXY·no_proxy
대부분의 CLI와 라이브러리는 소문자·대문자 변형을 모두 인식하는 경우가 많습니다. 관례적으로 다음을 같이 export 합니다.
http_proxy/HTTP_PROXY— HTTP 요청용https_proxy/HTTPS_PROXY— HTTPS 요청용(종종 HTTP 프록시 URL과 동일)ALL_PROXY— SOCKS 등 “모든 스킴”에 쓰이는 경우가 있음no_proxy/NO_PROXY— 내부망·로컬호스트 예외
예시는 mixed-port가 7890이고 HTTP 프록시로 쓰는 경우입니다. 본인 환경의 포트로 바꿉니다.
export http_proxy="http://127.0.0.1:7890" export https_proxy="http://127.0.0.1:7890" export HTTP_PROXY="$http_proxy" export HTTPS_PROXY="$https_proxy" export ALL_PROXY="socks5://127.0.0.1:7890" export no_proxy="127.0.0.1,localhost,::1" export NO_PROXY="$no_proxy"
SOCKS5만 쓰려면 ALL_PROXY=socks5://127.0.0.1:7891처럼 실제 SOCKS 포트에 맞추고, 일부 도구는 HTTP 프록시와 SOCKS를 동시에 요구하지 않으므로 과도한 중복은 피합니다. 회사 정책으로 인증이 붙은 프록시라면 http://사용자:비밀번호@호스트:포트 형태가 되지만, 로컬 Clash는 보통 인증 없이 루프백에만 열립니다.
macOS 터미널·로그인 셸
기본 셸이 zsh이면 ~/.zshrc, bash면 ~/.bash_profile 또는 ~/.bashrc에 위 줄을 넣습니다. GUI에서 연 터미널은 “로그인 셸” 여부에 따라 읽는 파일이 달라질 수 있어, 한 번 echo $SHELL과 실제로 파일이 로드되는지 확인하는 습관이 좋습니다.
Linux 데스크톱·SSH
SSH로 접속한 원격 세션은 서버 쪽 셸 프로필만 적용됩니다. 로컬 Clash가 있는 머신에서 작업한다면 위와 같이 127.0.0.1이 맞고, 원격 서버에서 “내 노트북의 Clash”를 쓰려면 방화벽·바인드·IP를 따로 설계해야 하므로 본문 범위를 벗어납니다.
4. Git: git config로 HTTP(S) 프록시 지정·해제
Git은 환경 변수를 따르기도 하지만, 저장소에 http.proxy가 박혀 있으면 그쪽이 우선되는 경우가 있습니다. 전역으로 넣을 때는 예를 들어 다음과 같습니다.
git config --global http.proxy http://127.0.0.1:7890 git config --global https.proxy http://127.0.0.1:7890
특정 호스트만 프록시하고 싶다면 http.https://github.com.proxy 형태의 URL 스코프 설정을 쓸 수 있습니다. 프록시를 끌 때는 git config --global --unset http.proxy 등으로 지웁니다. SSH([email protected]:)로 클론하는 경우는 HTTP 프록시와 별개로 ~/.ssh/config의 ProxyCommand·nc·connect 등이 필요할 수 있어, “HTTPS 클론은 되는데 SSH만 안 된다”면 프로토콜을 먼저 구분하세요.
5. npm·yarn·pnpm: 레지스트리와 프록시 설정
npm은 자체 설정 키가 있습니다.
npm config set proxy http://127.0.0.1:7890 npm config set https-proxy http://127.0.0.1:7890
환경 변수만으로도 동작하는 경우가 많지만, CI 스크립트나 오래된 .npmrc에 반대 값이 남아 있으면 충돌합니다. npm config list로 실제 적용 값을 확인하세요. yarn(Classic)은 yarn config set proxy 계열, pnpm은 환경 변수와 .npmrc를 함께 보는 경우가 많습니다. 모노레포·사내 레지스트리를 쓰면 no_proxy에 내부 도메인을 넣어 외부 노드만 Clash를 타게 하는 방식이 흔합니다.
패키지 설치가 여전히 느리면 “프록시 미적용”이 아니라 DNS·레지스트리 응답·디스크 I/O인 경우도 있습니다. 이때는 Clash 대시보드나 로그에서 해당 호스트가 어떤 정책에 매칭되는지 함께 보는 것이 좋습니다.
6. 영구 적용·sudo·백그라운드 작업
sudo npm install처럼 관리자 권한으로 실행하면 기본적으로 사용자 셸의 export가 비어 있는 환경에서 돌아가는 경우가 많습니다. 필요하면 sudo -E로 환경을 유지하거나, secure_path 정책을 확인하세요. systemd 유닛·크론 작업에서 npm을 돌릴 때는 유닛 파일의 Environment=에 동일한 프록시 변수를 넣는 방식이 안정적입니다.
프로젝트마다 프록시를 켜고 끄고 싶다면 direnv 등으로 디렉터리 단위 .envrc에만 변수를 두는 방법도 있습니다. “전역으로는 프록시 끔, 특정 폴더에서만 켬” 같은 운영에 잘 맞습니다.
7. 검증 순서: curl·env·Clash 로그
curl -I --proxy http://127.0.0.1:7890 https://example.com로 프록시 자체가 응답하는지 확인합니다.- 같은 셸에서
env | grep -i proxy로 철자·대소문자·끝의 슬래시 오타를 봅니다. git ls-remote https://github.com/...로 Git HTTPS 경로를 봅니다.npm ping또는 가벼운 패키지 설치로 레지스트리 왕복을 봅니다.
여기까지 통과하면 “터미널이 Clash를 안 탄다”는 문제는 대부분 해소됩니다. 통과하지 못하면 포트 충돌·다른 VPN·회사 PAC·프로필 덮어쓰기를 의심합니다.
8. 증상별로 어디를 볼까
| 증상 | 가능성이 큰 원인 | 먼저 할 일 |
|---|---|---|
| 브라우저만 되고 CLI만 실패 | 환경 변수·Git·npm 설정 미적용 | curl --proxy 검증 후 export·config 동기화 |
Connection refused on 127.0.0.1 |
포트 오타·Clash 미기동·다른 포트 사용 | UI·YAML에서 mixed-port 재확인 |
sudo로만 실패 |
프록시 환경이 root 세션에 없음 | sudo -E 또는 유닛 Environment= |
| HTTPS Git만 이상하고 SSH는 별개 | HTTP 프록시와 SSH 경로 분리 | 클론 URL을 https vs ssh로 구분·SSH ProxyCommand 검토 |
Windows·WSL2에서 호스트와 터미널의 127.0.0.1 의미가 달라지는 경우는 WSL2 점검 글을 참고하세요. 본문은 네이티브 macOS·Linux에 초점을 맞췄습니다.
9. 요약
시스템 프록시와 TUN이 켜져 있어도, 터미널 도구는 http_proxy·HTTPS_PROXY·ALL_PROXY와 Git·npm 자체 설정을 따로 맞춰야 하는 경우가 많습니다. 로컬 Clash의 mixed-port를 기준점으로 삼고, curl --proxy로 한 번 증명한 뒤 셸 프로필에 고정하면 이후 트러블슈팅이 단순해집니다. GUI 클라이언트는 규칙·노드·DNS를 다루기 쉽고, CLI는 변수 한 줄이 틀려도 바로 드러나는 편이라, 두 층을 나눠 생각하면 “브라우저만 된다”는 혼란이 줄어듭니다.
클라이언트 패키지는 출처가 분산되어 있어, 팀 단위로는 공식 다운로드 페이지를 표준으로 두면 버전과 업데이트 경로가 분명합니다. 오픈 소스 저장소는 라이선스·이슈 확인용으로 두고, 설치 파일 수령은 사이트 정책에 맞추는 편이 운영에 유리합니다.
→ Clash를 무료로 다운로드한 뒤, 터미널 환경 변수와 Git·npm만 맞춰도 개발 워크플로가 한결 안정됩니다