설정 실전 2026-08-28 약 17분 소요

Clash로 Notion·Figma·Miro 업무 환경 최적화하는 설정법

Notion 문서가 늦게 열리거나 Figma와 Miro 협업이 끊긴다면 Clash 라우팅을 조정해 보세요. 필요한 업무 도구만 프록시로 연결하고 국내 서비스는 직접 접속하는 실용적인 구성을 단계별로 소개합니다.

업무 도구만 프록시로 보내는 분리 라우팅 목표

Notion 문서가 한참 뒤에 열리거나 Figma 캔버스가 빈 화면으로 남고, Miro 보드의 커서와 댓글 동기화가 자주 끊긴다면 먼저 전체 트래픽을 무조건 프록시로 보내는 방식부터 점검해야 합니다. 업무 도구의 접속 품질은 단순히 노드의 핑이 낮다고 해결되지 않습니다. 문서 본문, 이미지와 첨부 파일, 로그인 인증, WebSocket 연결, 폰트와 분석 요청이 서로 다른 도메인으로 나뉘기 때문입니다.

이 글에서 사용할 기본 정책은 명확합니다. Notion·Figma·Miro와 해당 서비스가 실제로 사용하는 보조 도메인은 프록시 그룹으로 보내고, 국내 포털·사내 시스템·프린터·라우터 같은 주소는 DIRECT로 처리합니다. 이렇게 하면 업무 도구에는 안정적인 출구를 적용하면서도 국내 웹서비스의 지연과 구독 트래픽 사용량을 줄일 수 있습니다.

업무 프록시: Notion, Figma, Miro의 웹앱과 협업 연결을 하나의 정책 그룹으로 묶습니다.
국내 직결: GEOSITE,cn,DIRECT 또는 관리되는 국내 규칙 집합을 업무 도메인보다 아래쪽에 둡니다.
기본 출구: 마지막 MATCH,DIRECT 또는 MATCH,PROXY는 환경에 맞게 선택합니다. 업무용 설정에서는 예상하지 못한 해외 요청이 새어 나가지 않도록 기본 출구를 신중하게 정해야 합니다.

도메인 목록을 지나치게 넓히지 마세요

DOMAIN-KEYWORD,fig처럼 짧은 키워드를 사용하면 전혀 관계없는 사이트까지 프록시로 갈 수 있습니다. 우선 DOMAIN-SUFFIX로 공식 서비스의 기본 도메인을 지정하고, 로그에서 실제로 필요한 호스트만 추가하는 방식이 안전합니다.

클라이언트와 정책 그룹 준비

Clash Verge Rev, Clash for Windows 계열 대체 클라이언트, ClashX, Clash for Android, mihomo 기반 클라이언트는 화면 구성이 서로 다르지만 핵심은 같습니다. 먼저 mihomo 커널을 사용하는지 확인하고, 구독 프로필을 적용한 뒤 정책 그룹을 직접 추가하거나 기존 그룹 이름을 확인합니다. 메뉴에서는 보통 Profiles, Proxies, Rules, Settings와 비슷한 이름을 찾으면 됩니다.

정책 그룹 이름은 설정 파일의 규칙에서 정확히 일치해야 합니다. 예를 들어 실제 그룹 이름이 업무 프록시인데 규칙에 WORK라고 작성하면 해당 규칙을 불러오지 못하거나 예상하지 못한 기본 정책으로 처리될 수 있습니다. 이름을 영문으로 단순화하면 여러 클라이언트에서 호환성을 확인하기 쉽습니다.

정책 그룹	추천 용도	선택 기준
`WORK`	Notion·Figma·Miro	안정성이 좋은 지역 노드, 직접 선택
`AUTO`	업무용 자동 선택	지연 시간이 낮은 노드를 자동 테스트
`DIRECT`	국내 서비스와 내부망	프록시를 거치지 않고 로컬 네트워크로 연결
`REJECT`	명확한 차단 대상	업무와 무관한 광고·추적 요청을 선택적으로 차단

Figma와 Miro는 화면을 불러오는 HTTPS 요청 외에 실시간 협업을 위한 WebSocket 연결을 사용할 수 있습니다. 따라서 HTTP 웹페이지 하나만 열리는 노드보다 장시간 연결이 안정적인 노드를 선택하는 편이 좋습니다. 노드 이름의 국가 표시만으로 판단하지 말고, 실제로 파일을 열고 보드에 접속한 뒤 10분 이상 편집 상태를 유지하며 끊김과 재연결 횟수를 확인하세요.

Notion·Figma·Miro 규칙 작성 예시

아래 예시는 mihomo 계열 YAML 설정에서 사용할 수 있는 기본 골격입니다. 기존 구독 프로필에 이미 proxy-groups와 rules가 있다면 전체를 덮어쓰기보다 이름과 순서를 확인한 뒤 필요한 항목만 추가하세요. 서비스 제공사가 원격 규칙을 관리하는 프로필이라면 로컬 오버라이드 기능을 사용해야 할 수 있습니다.

proxy-groups:
  - name: WORK
    type: select
    proxies:
      - AUTO
      - DIRECT

  - name: AUTO
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,notion.so,WORK
  - DOMAIN-SUFFIX,notion.site,WORK
  - DOMAIN-SUFFIX,figma.com,WORK
  - DOMAIN-SUFFIX,figmausercontent.com,WORK
  - DOMAIN-SUFFIX,miro.com,WORK
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

notion.so는 웹앱과 API 요청의 주요 기준으로 사용할 수 있고, notion.site는 공개 페이지나 공유 페이지를 열 때 관련될 수 있습니다. Figma에서는 서비스 본체 외에 이미지와 파일 리소스가 별도 호스트에서 제공될 수 있으므로 캔버스는 열리지만 이미지가 늦게 나타나는 경우 로그에서 실제 도메인을 확인해야 합니다. figmausercontent.com은 예시로 포함했지만, 사용하는 환경의 응답과 정책에 따라 실제 호스트가 달라질 수 있습니다.

Miro도 보드 본체와 정적 리소스, 실시간 연결 호스트가 분리될 수 있습니다. 보드는 열리는데 다른 사용자의 커서나 새 카드가 갱신되지 않는다면 개발자 도구의 Network 탭 또는 Clash 연결 로그에서 WebSocket 요청의 호스트를 확인하세요. 확인한 호스트가 공식 서비스에 속한다고 판단될 때만 DOMAIN-SUFFIX 규칙을 추가합니다.

규칙 순서와 예외 처리

Clash 규칙은 위에서 아래로 검사하며 첫 번째로 일치한 줄에서 처리가 끝납니다. 따라서 업무 도메인을 국내 직결 규칙보다 위에 배치해야 합니다. 일부 서비스가 국내 CDN 주소를 사용하더라도 업무 도메인을 먼저 WORK로 지정하면 도메인 기준의 의도가 유지됩니다. 반대로 GEOSITE,cn,DIRECT를 맨 위에 두면 업무 서비스의 특정 호스트가 국내 분류로 판단되어 프록시를 거치지 않을 수 있습니다.

기존 규칙에서 로컬 네트워크와 사내망 예외를 확인합니다. 일반적으로 IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 같은 내부망 규칙은 업무 도메인보다 앞에 둡니다.
Notion·Figma·Miro의 명확한 기본 도메인을 WORK에 연결합니다.
앱을 실제로 사용하면서 실패한 요청의 호스트를 로그에서 확인합니다.
필요한 보조 도메인만 한 줄씩 추가하고, 매번 프로필을 저장한 뒤 다시 적용합니다.
마지막에는 국내 규칙과 MATCH를 배치해 미매칭 트래픽의 방향을 고정합니다.

DNS·TUN·앱 설정을 함께 조정하기

도메인 규칙을 작성했는데도 Notion 로그인 화면이 반복되거나 Figma가 빈 캔버스를 보여준다면 DNS와 트래픽 인수 범위를 확인해야 합니다. 시스템 프록시 모드는 HTTP와 HTTPS 프록시를 따르는 애플리케이션에 효과적이지만, 모든 데스크톱 앱과 UDP·DNS 요청을 자동으로 가져오는 것은 아닙니다. 브라우저와 데스크톱 앱의 동작이 서로 다를 때는 mihomo의 TUN 모드를 사용하는 편이 일관된 결과를 얻기 쉽습니다.

DNS: enhanced-mode: fake-ip를 사용하는 경우 가상 주소 대역인 198.18.0.1/16이 다른 로컬 규칙과 충돌하지 않는지 확인합니다. 사내 DNS가 필요한 도메인은 fake-ip-filter에 넣거나 사내 도메인만 별도 nameserver로 분리합니다.
TUN: Windows와 Android에서는 TUN 또는 VPN 권한을 허용해야 전체 앱 트래픽이 Clash로 들어옵니다. macOS에서는 네트워크 확장이나 헬퍼 권한 요청을 승인해야 하며, 권한이 꺼져 있으면 시스템 프록시만 동작할 수 있습니다.
브라우저 DoH: Chrome, Edge, Firefox의 보안 DNS가 별도 경로를 사용하면 Clash의 DNS 규칙과 결과가 달라질 수 있습니다. 테스트 중에는 브라우저의 보안 DNS를 일시적으로 끄거나 Clash가 처리하는 DNS 경로와 충돌하지 않도록 구성합니다.
Figma 데스크톱 앱: 앱 자체 프록시 설정이 있다면 시스템 프록시와 중복으로 지정하지 않습니다. 두 프록시가 겹치면 인증은 되지만 이미지 로딩이나 실시간 연결이 반복해서 재시도될 수 있습니다.
Miro 협업 연결: 회사 방화벽이나 보안 프로그램이 WebSocket을 차단하는 환경에서는 Clash 규칙만으로 해결되지 않습니다. 브라우저에서 보드가 열리는지, 다른 네트워크에서도 동일한지 비교해야 합니다.

사내 서비스는 별도 예외로 유지

사내 위키, Git 서버, 파일 공유 주소가 사설 IP나 사내 DNS 이름을 사용한다면 업무 도구를 프록시로 보내는 설정과 분리해야 합니다. DOMAIN-SUFFIX,internal.example,DIRECT와 사내 IP 대역의 IP-CIDR 규칙을 앞쪽에 두고, TUN을 켠 뒤에도 프린터·NAS·화상회의 장비가 정상적으로 보이는지 확인하세요. example은 문서 예시용 가상 도메인이므로 실제 사내 도메인으로 바꿔야 합니다.

업무 시나리오별 검증과 문제 해결

설정이 적용된 뒤에는 단순히 웹사이트 첫 화면이 보이는지만 확인하지 말고, 실제 업무 흐름을 순서대로 재현해야 합니다. 먼저 Clash의 로그 레벨을 info로 두고 필요한 경우에만 debug로 높입니다. 너무 높은 로그를 장시간 유지하면 화면이 복잡해지고 성능에도 영향을 줄 수 있습니다.

Notion: 로그인, 기존 페이지 열기, 새 블록 작성, 이미지 첨부, 페이지 공유 링크 열기를 차례로 시험합니다. 본문은 열리지만 첨부 이미지가 늦으면 이미지 호스트가 WORK 정책에 포함됐는지 확인합니다.
Figma: 파일 목록, 대형 디자인 파일, 코멘트 작성, 팀 라이브러리와 폰트 로딩을 확인합니다. 캔버스가 계속 회색이면 브라우저 콘솔과 Clash 로그에서 실패한 HTTPS 요청 및 WebSocket 재연결을 함께 살펴봅니다.
Miro: 보드 열기, 카드 이동, 다른 사용자와 실시간 커서 확인, 댓글과 이미지 업로드를 테스트합니다. 보드는 보이지만 실시간 변경만 늦으면 일반 웹 요청이 아니라 장시간 연결 경로를 의심해야 합니다.
국내 서비스: 국내 포털, 은행 또는 사내 서비스에 접속해 연결 로그의策略이 DIRECT로 표시되는지 확인합니다. 같은 도메인이 프록시와 직결 사이를 오가면 규칙 중복과 원격 프로필의 우선순위를 점검합니다.

증상	우선 확인할 항목	조정 방법
Notion 로그인 반복	인증 도메인, 브라우저 쿠키, DNS	로그에서 인증 호스트를 확인하고 같은 정책으로 연결
Figma 캔버스 빈 화면	보조 리소스 호스트, TUN 권한	실패한 호스트를 확인해 필요한 suffix만 추가
Miro 변경 사항 지연	WebSocket 재연결, 노드 안정성	안정적인 노드로 고정하고 방화벽 차단 여부 비교
국내 사이트까지 느려짐	GEOSITE·GEOIP 순서, MATCH 정책	국내 규칙을 업무 규칙 아래에 두고 DIRECT 여부 확인
사내 프린터·NAS 미탐지	TUN의 auto-route, 로컬 IP 예외	사설 대역과 로컬 도메인을 DIRECT 및 bypass 대상으로 설정

문제가 발생했을 때 여러 옵션을 한꺼번에 바꾸지 않는 것도 중요합니다. 먼저 정책 그룹에서 노드를 수동 선택하고, 다음으로 도메인 규칙을 확인한 뒤, 마지막에 DNS와 TUN을 조정하세요. 노드를 바꾼 뒤 문제가 사라지면 규칙보다 출구 품질이 원인일 가능성이 높습니다. 반대로 어떤 노드를 선택해도 특정 리소스만 실패한다면 누락된 도메인이나 앱의 별도 네트워크 경로를 조사해야 합니다.

설정이 안정화되면 규칙을 필요한 수준으로 정리하고, 구독 프로필을 갱신할 때 로컬 수정 사항이 덮어써지지 않는지 확인하세요. 백업 파일에는 구독 주소가 포함될 수 있으므로 공개 폴더나 공유 문서에 저장하지 않는 것이 좋습니다. 플랫폼별 설치와 기본 모드 설정이 아직 끝나지 않았다면 사용법 확인 후 다운로드 센터에서 사용하는 클라이언트에 맞는 절차를 진행하세요.

자주 나타나는 오류와 원인별 해결법

증상	가능한 원인	확인할 항목
로그인 명령이 즉시 연결 거부	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 기반 클라이언트를 확인하고, 적용 후에는 단계별 튜토리얼에 따라 프로필과 프록시 모드를 설정하세요.

전방위 다운로드 설정 튜토리얼