ClashX Pro macOS 시스템 프록시 설정과 자동 켜기 방법
ClashX Pro를 처음 사용하는 Mac 사용자를 위해 시스템 프록시 설정 과정을 단계별로 정리했습니다. 올바른 메뉴에서 프록시를 활성화하고 선택한 노드가 실제로 적용되는지 확인하는 방법, 연결되지 않을 때 점검할 항목까지 함께 안내합니다.
ClashX Pro와 macOS 시스템 프록시의 관계
ClashX Pro는 macOS 메뉴 막대에서 구성을 선택하고, 선택한 프록시 노드로 애플리케이션의 네트워크 요청을 전달하는 클라이언트입니다. 여기서 자주 혼동하는 부분은 “노드를 선택했다”는 것과 “macOS 전체에 프록시가 적용됐다”는 것이 서로 다른 단계라는 점입니다. 노드와 설정 파일을 불러온 뒤에도 시스템 프록시가 꺼져 있으면 Safari나 시스템 프록시를 따르는 앱은 일반 네트워크로 직접 연결됩니다.
ClashX Pro의 시스템 프록시 기능은 macOS 네트워크 설정에 HTTP 프록시와 HTTPS 프록시, 필요할 경우 SOCKS 프록시 정보를 등록하는 방식으로 작동합니다. 따라서 모든 앱이 자동으로 ClashX Pro를 사용하는 것은 아닙니다. Safari, 많은 macOS 기본 앱, 시스템 프록시를 따르는 일반적인 데스크톱 프로그램은 적용되지만, 자체 프록시 설정이나 자체 DNS를 사용하는 앱은 별도로 설정해야 할 수 있습니다.
반대로 시스템 프록시는 TUN 모드와도 다릅니다. 시스템 프록시는 애플리케이션이 macOS의 프록시 설정을 읽을 때만 동작하는 반면, TUN은 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 가로채는 방식입니다. ClashX Pro에서 특정 앱이 계속 직접 연결된다면 단순히 노드를 바꾸기보다 해당 앱이 시스템 프록시를 지원하는지부터 확인해야 합니다.
먼저 확인할 세 가지
ClashX Pro가 실행 중인지, 사용할 구성이 현재 활성화되어 있는지, 메뉴 막대에서 시스템 프록시가 켜져 있는지를 순서대로 확인하세요. 이 세 조건 중 하나라도 빠지면 노드 목록이 정상적으로 보여도 웹사이트에는 프록시가 적용되지 않을 수 있습니다.
설정 전 준비: 구성과 노드 상태 확인
시스템 프록시를 켜기 전에 먼저 ClashX Pro가 사용할 설정 파일을 준비해야 합니다. 구독 링크를 제공받았다면 ClashX Pro의 프로파일 또는 설정 가져오기 메뉴에서 URL을 등록하고, 다운로드가 끝난 뒤 해당 프로파일을 활성화합니다. 설정 파일이 비어 있거나 구독 갱신에 실패한 상태에서는 시스템 프록시를 켜도 전달할 노드가 없어 연결이 실패합니다.
- ClashX Pro를 응용 프로그램 폴더에 설치하고 실행합니다. 처음 실행할 때 macOS가 앱 실행을 차단하면 시스템 설정의 개인정보 보호 및 보안에서 허용 절차를 진행합니다.
- 메뉴 막대의 ClashX Pro 아이콘을 클릭한 뒤 설정 또는 프로파일 관련 메뉴를 엽니다. 사용하는 버전에 따라 메뉴 이름은 Profiles, Config 또는 설정 목록처럼 표시될 수 있습니다.
- 서비스 제공사가 발급한 구독 URL을 추가하고 다운로드가 완료될 때까지 기다립니다. URL에는 계정 인증 정보가 포함될 수 있으므로 공개 채팅이나 게시판에 붙여넣지 마세요.
- 가져온 프로파일을 선택해 활성화한 뒤 Proxy 또는 노드 선택 메뉴에서 사용할 노드를 지정합니다. 노드명이 표시되지 않으면 먼저 프로파일 갱신 상태를 확인합니다.
- 노드 지연 시간이나 연결 테스트 결과를 확인합니다. 지연 시간이 낮은 노드가 항상 실제 웹 접속에 가장 안정적인 것은 아니므로, 선택 후 실제 페이지 접속도 함께 확인해야 합니다.
| 확인 항목 | 정상 상태 | 문제가 있을 때 |
|---|---|---|
| ClashX Pro 실행 | 메뉴 막대에 아이콘이 표시됨 | 앱을 다시 실행하고 권한 알림 확인 |
| 활성 프로파일 | 설정 목록에 선택 표시가 있음 | 프로파일 다운로드 또는 YAML 오류 점검 |
| 선택 노드 | 정책 그룹에서 특정 노드가 선택됨 | 그룹을 열어 실제 출구 노드 지정 |
| 시스템 프록시 | 메뉴에서 활성화 상태로 표시됨 | 아래 macOS 네트워크 설정에서 프록시 항목 확인 |
ClashX Pro 시스템 프록시 켜기
이제 실제로 macOS 시스템 프록시를 활성화합니다. ClashX Pro 버전에 따라 메뉴 문구가 조금 다를 수 있지만, 핵심은 메뉴 막대 아이콘에서 Set as system proxy, 시스템 프록시 설정 또는 이와 비슷한 항목을 찾는 것입니다. 항목에 체크 표시가 나타나면 macOS 네트워크 서비스에 프록시 설정이 반영된 상태입니다.
메뉴 막대에서 빠르게 켜는 방법
- 화면 오른쪽 위 메뉴 막대에서 ClashX Pro 아이콘을 클릭합니다.
- Proxy 또는 정책 그룹 메뉴에서 사용할 노드를 선택합니다. 자동 선택 그룹을 사용한다면 현재 선택된 실제 노드가 무엇인지 펼쳐서 확인합니다.
- Set as system proxy 또는 시스템 프록시 설정 항목을 클릭해 체크 상태로 만듭니다.
- macOS 로그인 암호나 관리자 인증을 요청하면 시스템 네트워크 설정을 변경하기 위한 정상적인 권한 절차이므로 현재 계정의 암호를 입력합니다.
- Safari를 완전히 종료한 뒤 다시 실행하고, 외부 IP 확인 페이지나 접속하려는 사이트를 열어 출구가 변경됐는지 확인합니다.
macOS 설정에서 적용 여부 확인
메뉴 막대에서 켰다는 표시만으로 판단하지 말고 macOS 설정에서도 확인하는 것이 좋습니다. macOS 13 Ventura 이후에는 시스템 설정 › 네트워크 › 사용 중인 네트워크 서비스 › 세부사항 › 프록시로 이동합니다. macOS의 세부 버전에 따라 메뉴 이름이 네트워크 환경설정 또는 고급 설정으로 표시될 수 있습니다.
프록시 화면에서 웹 프록시(HTTP)와 보안 웹 프록시(HTTPS)가 활성화되어 있고 서버 주소와 포트가 ClashX Pro의 로컬 포트와 일치하는지 확인합니다. 일반적으로 HTTP 포트는 7890, SOCKS 포트는 7891처럼 설정되는 경우가 많지만, 실제 값은 사용 중인 프로파일과 클라이언트 설정을 우선해야 합니다. 다른 프로그램이 해당 포트를 이미 사용하면 ClashX Pro가 시스템 프록시를 정상적으로 등록하지 못할 수 있습니다.
포트 번호를 임의로 바꾸지 마세요
온라인 예시의 7890 또는 7891을 그대로 입력하기보다 ClashX Pro 설정 화면에 표시된 HTTP와 SOCKS 포트를 기준으로 입력하세요. 포트가 서로 바뀌면 브라우저가 연결되지 않거나 SOCKS 전용 포트에 HTTP 요청을 보내는 오류가 발생할 수 있습니다.
실제로 적용됐는지 검증하는 방법
프록시 아이콘이 켜져 있다는 사실만으로는 충분하지 않습니다. 애플리케이션이 실제로 ClashX Pro의 로컬 포트에 연결하고, 선택한 노드에서 외부로 나가는지 단계별로 확인해야 합니다. 검증할 때는 Safari와 터미널을 함께 사용하면 메뉴 표시와 실제 통신 결과를 교차 확인할 수 있습니다.
- ClashX Pro의 시스템 프록시를 켜고, 선택한 노드가 연결 가능한 상태인지 확인합니다.
- Safari에서 평소 직접 연결할 때와 다른 외부 IP 또는 지역이 표시되는지 확인합니다. IP가 바뀌지 않는다면 시스템 프록시가 꺼져 있거나 Safari가 다른 네트워크 설정을 사용하고 있을 수 있습니다.
- 터미널에서
scutil --proxy를 실행합니다. HTTPEnable 또는 HTTPSEnable 값이1인지, 서버와 포트가 ClashX Pro의 로컬 리슨 포트와 일치하는지 확인합니다. - 필요하면
curl -I https://example.com으로 응답 헤더를 확인합니다. 이 결과만으로 출구 노드를 단정할 수는 없지만, 브라우저와 별개로 시스템 프록시를 따르는 명령행 요청이 성공하는지 판단하는 데 도움이 됩니다. - ClashX Pro의 연결 또는 로그 화면에서 방금 실행한 도메인 요청이 기록되는지 확인합니다. 요청이 로그에 없으면 해당 앱이 시스템 프록시를 사용하지 않았을 가능성이 큽니다.
| 증상 | 가능성이 높은 원인 | 확인 방법 |
|---|---|---|
| Safari는 연결되지만 특정 앱만 직접 연결 | 앱이 시스템 프록시를 무시함 | 앱 자체의 HTTP, SOCKS 또는 PAC 설정 확인 |
| 모든 사이트가 연결되지 않음 | 잘못된 로컬 포트, 노드 장애, 프로파일 오류 | Clash 로그와 시스템 프록시 포트 대조 |
| 프록시를 켜도 외부 IP가 그대로임 | 시스템 프록시 미적용 또는 직접 연결 규칙 | scutil --proxy와 활성 노드 확인 |
| 잠시 후 연결이 끊김 | 앱 종료, 노드 만료, 네트워크 전환 | 메뉴 막대 상태와 프로파일 갱신 시간 확인 |
로그인 시 자동 실행과 연결 문제 해결
매번 ClashX Pro를 수동으로 실행하고 시스템 프록시를 켜는 과정이 번거롭다면 macOS 로그인 항목에 ClashX Pro를 추가할 수 있습니다. 시스템 설정 › 일반 › 로그인 항목으로 이동한 뒤 로그인 시 열리는 앱 목록에 ClashX Pro를 추가하세요. 일부 버전의 ClashX Pro에는 자체 환경설정 안에 로그인 시 실행 또는 시작 시 자동 실행 항목이 있을 수 있으므로, 앱 내부 설정과 macOS 로그인 항목 중 하나만 사용해 중복 실행을 피하는 것이 좋습니다.
자동 실행과 자동 프록시 적용은 같은 기능이 아닙니다. ClashX Pro가 로그인 때 실행되더라도 시스템 프록시가 자동으로 켜지지 않는 버전이 있으므로, 앱 설정에 시스템 프록시 자동 설정 옵션이 있는지 확인해야 합니다. 해당 옵션이 없다면 로그인 후 메뉴 막대에서 시스템 프록시 상태를 한 번 확인하는 습관이 안전합니다. 프록시가 켜진 상태에서 Mac을 종료하거나 네트워크를 전환하면 다음 로그인 때 설정이 남아 있을 수 있지만, 프로파일 갱신이나 권한 상태에 따라 다시 꺼질 수도 있습니다.
연결되지 않을 때의 점검 순서
- 프로파일 확인: 구독 URL이 만료되지 않았는지, 설정 파일에 문법 오류가 없는지 확인합니다. 프로파일을 다시 갱신한 뒤 새로 활성화하면 오래된 노드 정보 문제를 분리할 수 있습니다.
- 노드 변경: 특정 노드만 실패하는지 확인하기 위해 같은 정책 그룹에서 다른 노드를 선택합니다. 모든 노드가 실패하면 로컬 포트나 네트워크 자체를 먼저 점검합니다.
- 시스템 프록시 초기화: ClashX Pro에서 시스템 프록시를 끈 뒤 다시 켭니다. macOS의 프록시 화면에 오래된 서버 주소나 포트가 남아 있다면 사용하지 않는 항목을 정리합니다.
- 다른 VPN과 프록시 종료: 다른 VPN, 네트워크 필터, 브라우저 확장 프로그램이 같은 트래픽을 가로채면 연결 순서가 꼬일 수 있습니다. 문제를 재현할 때는 다른 도구를 잠시 종료합니다.
- DNS와 앱 설정 확인: 웹페이지는 열리지만 특정 도메인만 실패하면 DNS 또는 앱 자체의 DoH 설정을 확인합니다. 시스템 프록시가 DNS 요청까지 자동으로 프록시 처리한다는 뜻은 아닙니다.
- 로그 확인: 연결 거부, TLS 오류, timeout, no route 같은 메시지를 시간순으로 확인합니다. 단순히 오류 로그 한 줄만 보고 모든 노드가 고장 났다고 판단하지 말고, 다른 노드와 다른 사이트로 재현하세요.
사용을 마친 뒤에는 프록시 상태도 확인
공용 네트워크에서만 프록시를 사용한다면 작업이 끝난 뒤 시스템 프록시를 끄는 것이 좋습니다. 프록시 앱을 종료했는데 macOS 설정에 서버와 포트가 남아 있으면 이후 인터넷 연결이 실패할 수 있으므로, ClashX Pro를 종료하기 전 시스템 프록시 해제 상태를 확인하세요.
안정적인 운영을 위한 설정 기준
ClashX Pro를 macOS에서 안정적으로 사용하려면 “앱 실행, 프로파일 활성화, 노드 선택, 시스템 프록시 적용”의 네 단계를 분리해서 기억하는 것이 좋습니다. 자동 실행을 설정한 뒤에도 노드 만료나 구독 갱신 실패는 별도로 발생할 수 있으므로, 연결이 느려졌을 때 곧바로 macOS 전체 문제로 단정하지 말고 프로파일과 노드 상태부터 확인하세요.
또한 시스템 프록시를 켜면 모든 트래픽이 무조건 같은 노드로 이동한다고 생각해서는 안 됩니다. Clash 설정의 rules와 정책 그룹에 따라 국내 도메인은 DIRECT로 전달되고 특정 서비스만 프록시로 이동할 수 있습니다. 외부 IP가 예상과 다르게 보인다면 시스템 프록시 자체보다 현재 모드가 Rule인지 Global인지, 기본 정책 그룹이 무엇인지 확인하는 편이 정확합니다.
처음 사용하는 경우에는 먼저 Safari 한 개로 시스템 프록시 적용 여부를 확인한 다음, 필요한 앱을 하나씩 추가하는 방식이 안전합니다. 연결이 정상화된 뒤 자동 실행을 설정하면 문제 발생 시 어느 단계에서 오류가 생겼는지 추적하기 쉽고, 사용하지 않는 앱까지 불필요하게 프록시를 통과시키는 상황도 줄일 수 있습니다.
ClashX Pro 사용 준비 마무리
macOS 시스템 프록시는 ClashX Pro에서 노드를 선택한 뒤 별도로 활성화해야 하며, scutil --proxy와 실제 웹 접속을 함께 확인해야 적용 여부를 정확히 판단할 수 있습니다. 자동 실행을 설정할 때는 앱 실행과 프록시 자동 적용을 구분하고, 연결 문제가 생기면 프로파일·노드·포트·다른 VPN 순서로 점검하세요.
자주 나타나는 오류와 원인별 해결법
| 증상 | 가능한 원인 | 확인할 항목 |
|---|---|---|
| 로그인 명령이 즉시 연결 거부 | Clash가 꺼져 있거나 포트가 다름 | mixed-port, HTTP 포트, 로컬 리스닝 상태 |
| 브라우저 인증은 끝났지만 CLI가 대기 | 콜백 주소가 프록시나 보안 프로그램에 의해 차단됨 | localhost를 NO_PROXY에 포함했는지 확인 |
| TLS handshake timeout | 노드 품질 저하, 잘못된 규칙, MTU 문제 | Clash 로그, 다른 노드, TUN 사용 여부 |
| 인증 성공 후 요청만 실패 | API 요청이 다른 호스트로 이동하거나 규칙에서 DIRECT 처리됨 | 요청 도메인의规则匹配 결과와 프록시 그룹 |
| 명령을 찾을 수 없음 | CLI 설치 경로가 PATH에 없음 | codex --help, 운영체제 PATH, 설치 방식 |
| 인증 정보가 반복해서 사라짐 | 권한 문제, 임시 컨테이너, 자격 증명 저장 실패 | 설정 디렉터리 쓰기 권한과 실행 환경 |
로그인 콜백이 멈추는 경우에는 NO_PROXY가 지나치게 넓게 설정되지 않았는지 확인하세요. localhost와 127.0.0.1은 로컬 콜백을 위해 직접 연결하는 것이 일반적이지만, 외부 인증 서버 도메인을 무심코 NO_PROXY에 넣으면 브라우저 인증 페이지와 CLI의 인증 요청이 서로 다른 경로로 나갈 수 있습니다.
반대로 TUN 모드에서 localhost까지 가상 인터페이스로 보내면 콜백 서버가 정상적으로 응답하지 않을 수 있습니다. 이런 환경에서는 DNS 하이재킹과 자동 라우팅을 켜더라도 로컬 주소 예외를 유지하세요. TUN을 켠 뒤 문제가 시작됐다면 TUN을 끄고 환경 변수 방식으로 재시험하면 원인을 빠르게 분리할 수 있습니다.
프록시 오류와 인증 오류를 구분하세요
“connection refused”, “timeout”, “TLS handshake”는 대체로 네트워크 경로 문제이고, 인증 만료·권한 부족·잘못된 계정은 서버가 반환하는 인증 단계의 오류입니다. 전자는 Clash 로그와 포트를 먼저 보고, 후자는 Codex CLI의 로그아웃 후 재로그인과 계정 권한을 확인해야 합니다.
TUN과 DNS를 사용할 때의 추가 점검
Codex CLI가 실행하는 셸 명령이나 패키지 도구까지 같은 네트워크 정책으로 처리해야 한다면 TUN 모드가 편리할 수 있습니다. 다만 TUN은 단순히 브라우저를 프록시로 바꾸는 기능이 아니라 시스템 라우팅과 DNS 흐름을 변경하는 기능입니다. Windows에서는 서비스 모드와 관리자 권한이 필요할 수 있고, macOS에서는 네트워크 확장 또는 VPN 구성 허용이 요구될 수 있습니다.
mihomo 기반 클라이언트에서는 auto-route, auto-detect-interface, dns-hijack 설정이 서로 맞물립니다. 자동 라우팅이 꺼져 있으면 TUN 인터페이스가 만들어져도 일부 트래픽이 기존 네트워크 카드로 빠질 수 있습니다. DNS 하이재킹이 빠지면 도메인 조회는 운영체제 DNS로 남아 규칙 매칭이 불안정해질 수 있습니다. fake-ip을 사용하는 경우 198.18.0.1/16과 같은 가상 대역이 로컬 네트워크 규칙에 의해 차단되지 않는지도 확인하세요.
- Clash 로그에서 DNS 요청이 기록되는지 확인합니다.
nslookup또는dig결과가 매번 바뀌는지, 특정 잘못된 주소가 반복되는지 비교합니다.- 사내 도메인과 로컬 프린터 주소는
NO_PROXY또는 DIRECT 규칙으로 분리합니다. - 패키지 설치 명령이 실패하면 Codex 자체가 아니라 패키지 저장소의 인증서, 별도 프록시 설정, 저장소 정책을 확인합니다.
터미널 명령 실행을 허용할 때는 네트워크가 안정적이라는 이유만으로 모든 명령을 자동 승인하지 마세요. Codex CLI가 파일을 수정하거나 외부 패키지를 설치하도록 설정되어 있다면 프로젝트 디렉터리, 셸 권한, 환경 변수에 저장된 비밀 정보까지 함께 고려해야 합니다. 먼저 읽기 작업으로 검증하고, 변경 작업은 명령별로 확인하는 것이 안전합니다.
FAQ: Codex CLI와 Clash 연결 문제
시스템 프록시를 켰는데도 Codex CLI가 직접 연결되는 이유는 무엇인가요?
터미널 프로그램이나 내부 HTTP 라이브러리가 운영체제의 시스템 프록시를 읽지 않을 수 있습니다. 현재 셸에 HTTP_PROXY와 HTTPS_PROXY를 직접 지정한 뒤 다시 실행하세요. 그래도 로그가 보이지 않으면 TUN 모드로 비교 테스트를 진행해 프로세스가 프록시 변수를 무시하는지 확인할 수 있습니다.
HTTP_PROXY와 HTTPS_PROXY에 서로 다른 포트를 넣어야 하나요?
Clash의 mixed 포트를 사용한다면 두 변수에 같은 HTTP 주소를 넣어도 됩니다. 다만 실제 클라이언트에서 HTTP와 SOCKS 포트가 분리되어 있다면 HTTPS 요청에 SOCKS 포트를 HTTP 주소로 입력하지 않도록 주의하세요. 포트 형식과 프로토콜이 맞지 않으면 연결 거부 또는 TLS 오류가 발생합니다.
Codex 로그인 후에는 환경 변수를 삭제해도 되나요?
로그인 정보가 안전하게 저장되고 이후 요청이 직접 연결로도 허용되는 환경이라면 가능하지만, 인증 후 API 요청도 프록시가 필요한 네트워크라면 환경 변수를 계속 유지해야 합니다. 테스트할 때는 변수를 삭제한 새 셸에서 간단한 요청을 실행해 인증 경로와 실제 작업 경로가 모두 정상인지 구분하세요.
노드를 바꾸면 Codex CLI 인증을 다시 해야 하나요?
일반적으로 노드 변경만으로 저장된 인증 정보가 사라지지는 않습니다. 그러나 출구 지역이나 IP가 바뀌면서 보안 확인이 추가되거나, 이전 연결이 만료되어 재인증이 요구될 수 있습니다. 짧은 시간에 여러 지역의 노드를 반복해서 바꾸기보다 안정적인 하나의 그룹을 선택하고 Clash 로그에서 연결 상태를 확인하세요.
다음 단계: Clash 설정과 Codex 실행 환경 정리
Codex CLI 연결 문제는 대부분 클라이언트 자체보다 로컬 포트, 셸 환경 변수, DNS 경로, 규칙 순서 중 하나에서 발생합니다. 먼저 mixed 포트와 전역 연결을 이용해 기본 경로를 검증한 뒤, 규칙 모드와 TUN 모드로 범위를 좁히면 불필요한 설정 변경을 줄일 수 있습니다. 설치 파일과 클라이언트 선택이 아직 정해지지 않았다면 다운로드 센터에서 플랫폼에 맞는 mihomo 기반 클라이언트를 확인하고, 적용 후에는 단계별 튜토리얼에 따라 프로필과 프록시 모드를 설정하세요.