증상을 한 줄로 고정하고 재현 순서 만들기

먼저 증상을 구체화합니다. 「Clash 켜면 AnyConnect가 끊긴다」만으로는 부족하고, 연결 직후 몇 초 만에 끊기는지, 특정 앱만 사내망이 안 되는지, DNS만 깨지는지에 따라 의심 스택이 달라집니다. Clash를 끄면 즉시 정상이면, 대개 Clash의 규칙·TUN·시스템 프록시가 VPN 흐름을 가로채거나 라우트 우선순위를 바꾼 경우입니다. 반대로 Clash를 꺼도 동일하면 회사 게이트웨이·인증서·분할 터널 정책 쪽을 먼저 봐야 합니다. Clash와 전통 VPN의 차이를 짚어 두면, 「전역 터널 VPN」과 「애플리케이션·도메인 분류 프록시」가 같은 OS에서 어떻게 겹치는지 설계 관점이 잡힙니다.

재현 절차는 간단할수록 좋습니다. 예: AnyConnect 연결 → 내부 포턼 IP 또는 호스트명 접속 → Clash TUN ON → 30초 내 끊김 여부. 같은 순서를 유지해야 라이브 연결 로그와 OS 라우트 덤프를 시간축으로 맞출 수 있습니다. 클라이언트 UI가 읽기 쉬운지는 Clash 클라이언트 선택에서도 다루는데, VPN과 같이 쓸 때는 연결별 정책 적중이 한눈에 보이는 쪽이 유리합니다.

ℹ 로그 먼저: 문제가 난 직후 Clash에서 해당 플로우가 DIRECT인지 특정 프록시 그룹인지 확인하세요. 동시에 OS에서 vpnclient·회사 인터페이스로 나가야 할 목적지가 어떤 인터페이스에 붙는지 메모해 두면, 이후 단계에서 되돌리기 쉽습니다.

0단계: 회사 정책·분할 터널 여부 확인

일부 조직은 개인 프록시·로컬 터널 자체를 금지하거나, 보안 에이전트와 충돌 시 접속을 끊도록 설정합니다. 본문은 기술적 공존을 설명하지만, 정책 위반이 될 수 있는 방법을 권장하지 않습니다. IT 헬프데스크 가이드에 「분할 터널(split tunnel) 허용」「특정 대역만 VPN」 등이 있으면 Clash 쪽 DIRECT 설계가 단순해집니다. 반대로 풀 터널이면 일반 웹도 회사 출구로 나가므로, Clash 규칙만으로는 체감이 다르게 보일 수 있습니다. 브라우저 M365·Copilot 분류처럼 업무 SaaS를 별도로 다루는 글과 달리, 여기서는 IP 레이어·라우팅 비중이 큽니다.

1단계: 규칙·정책 그룹에서 VPN 트래픽 빼기

AnyConnect는 UDP/443 또는 DTLS, SSL/TLS 조합으로 게이트웨이와 세션을 유지합니다. 이 흐름이 Clash에서 외국 노드로 나가면 지연·차단·세션 리셋으로 「갑자기 끊김」처럼 보일 수 있습니다. 해결의 첫 축은 도메인·프로세스·IP 중 무엇으로 묶을지 정하는 것입니다. 게이트웨이가 고정 호스트명이면 DOMAIN-SUFFIX나 DOMAIN으로 VPN 전용 정책 그룹을 만들고 그 안을 DIRECT로 두는 패턴이 흔합니다. 호스트명을 모르면 연결 시점에 Clash 라이브 로그에서 이름을 수집하세요. 규칙 위쪽에 둘수록 안전합니다. 규칙 분류 모범 사례에서 말하듯, 광범위한 RULE-SET이 VPN 호스트보다 위에 있으면 계속 덮어씁니다.

Windows에서는 PROCESS-NAME으로 vpnui.exe·vpnagent.exe 등을 DIRECT에 묶는 방법도 있습니다. 다만 벤더·버전마다 실행 파일 이름이 다르므로 작업 관리자로 실제 프로세스를 확인하세요. 규칙만 고치고도 증상이 남으면 TUN이 여전히 가로채는지 의심합니다.

2단계: VPN 게이트웨이·사내망 IP-CIDR을 DIRECT로

호스트명 규칙만으로는 부족한 경우가 많습니다. AnyConnect가 붙은 뒤에는 사내망 RFC1918 대역(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)이나 회사 전용 공인 대역이 인터페이스에 추가됩니다. 이 트래픽이 Clash의 기본 MATCH에서 프록시로 나가면 내부 서버가 안 열리거나 반쪽으로 열립니다. 운영에서는 실제로 쓰는 대역만 IP-CIDR·IP-CIDR6로 DIRECT에 올리고, 불필요하게 넓은 대역을 영구화하기 전에 IT 문서와 맞추는 것이 안전합니다. IPv6 이중 스택이 켜져 있으면 v4만 맞춰도 v6로 새 나가기 때문에, IPv6·DNS 유출 정리 글과 함께 보는 편이 좋습니다.

사내망에 분할 DNS가 있으면, 내부 전용 존을 외부 리졸버로내면 NXDOMAIN·잘못된 A 레코드가 나와 VPN은 붙어 있는데도 「앱만 실패」할 수 있습니다. 이 경우 DNS 단계(다음 절)와 규칙을 같이 봅니다.

Illustrative rules (adjust to your network)

rules:
  # VPN gateway hostname from your IT portal
  - DOMAIN,vpn.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  # RFC1918 corporate ranges (narrow if possible)
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - MATCH,PROXY_GROUP

3단계: TUN vs 시스템 프록시·적중 로그로 우선순위 확정

TUN 모드는 커널이 보내는 패킷을 가로채므로, 회사 VPN과 동시에 켜면 라우팅 싸움이 나기 쉽습니다. AnyConnect는 자체 가상 인터페이스와 라우트를 추가하는데, Clash TUN도 기본 라우트나 더 구체적인 라우트를 넣을 수 있어 메트릭에 따라 승자가 바뀝니다. 증상이 TUN ON에서만 나면, 당분간 시스템 프록시만 사용하는 구성으로 바꿔 재현해 보고, 라이브 로그로 실제 적중을 비교하세요. TUN 심화에서 다루는 것처럼, 브라우저·터미널·VPN 클라이언트가 서로 다른 경로를 탈 수 있습니다. macOS에서는 시스템 확장·다른 패킷 필터와의 순서도 변수입니다. macOS TUN·프록시 충돌 글의 체크리스트를 같이 보세요.

TUN을 끄고도 시스템 프록시가 남아 이상하게 동작한다면, 종료 후 프록시·TUN 잔류 정리 흐름으로 OS 쪽을 먼저 비웁니다. VPN과 Clash를 자주 토글하는 사용자에게는 종료 시 복원 동작이 분명한 GUI를 고르는 것이 피로도를 줄입니다.

4단계: OS 라우팅 테이블·메트릭·인터페이스 순서

Windows에서는 route print·PowerShell Get-NetRoute로, macOS·Linux에서는 netstat -rn 또는 ip route로 테이블을 덤프합니다. AnyConnect 연결 전후를 비교해 어떤 prefix가 어떤 인터페이스로 붙는지 봅니다. Clash TUN이 비슷한 목적지에 더 낮은 메트릭으로 붙어 있으면 패킷이 VPN이 아닌 TUN으로 들어가 버립니다. 이 경우 클라이언트에서 TUN 자동 라우트 범위를 줄이거나, VPN이 요구하는 대역을 Clash보다 위에 두는 OS 쪽 조정이 필요할 수 있습니다. 세부 UI는 제품마다 다르므로, 여기서는 「덤프를 두 번 비교한다」는 행동만 고정합니다.

사내망이 링크 로컬·캡티브 포털·프록시 PAC에 의존하는 경우, Clash가 PAC을 우회하면 포턼만 맴돌 수 있습니다. 이때는 브라우저가 아닌 OS의 PAC 설정과 Clash의 관계를 따로 점검합니다.

5단계: DNS·fake-ip·dns-hijack과 내부 리졸버

VPN이 연결되면 내부 DNS 서버가 가상 어댑터를 통해 노출되는 경우가 많습니다. Clash가 dns-hijack으로 53번 포트를 잡아도, DoH로 우회하면 여전히 외부 리졸버를 탈 수 있습니다. fake-ip를 쓰면 규칙 판단은 단순해지지만, VPN 내부 이름이 규칙에 없으면 잘못된 가짜 IP로 붙어 TCP가 실패합니다. 이때는 Meta DNS·nameserver·fallback 글의 축으로 nameserver 정책을 정리하고, 내부 접미사를 nameserver-policy 등으로 VPN 쪽 리졸버에 붙이는 패턴을 검토합니다. 브라우저 Secure DNS를 잠시 끄고 대조 실험하는 것도 비용 대비 효과가 큽니다.

LAN 공유·바인드 주소를 다룬 LAN 공유·방화벽 글과 겹치는 부분은, 로컬 브로드캐스트·mDNS가 Clash 레이어에서 가려질 때입니다. VPN과는 다른 축이지만, 「내부 이름이 안 풀린다」 증상이 비슷해 보일 수 있어 참고합니다.

GlobalProtect·기타 SSL VPN에도 통하는 체크

Palo Alto GlobalProtect도 SSL VPN 계열에서 비슷한 증상이 납니다. 포턼 호스트·게이트웨이·내부 라우트 주입 방식만 다를 뿐, Clash와의 충돌 패턴은 「규칙이 VPN을 프록시했다」「TUN이 라우트를 이겼다」「DNS가 내부를 못 본다」로 수렴합니다. 벤더 문서에 있는 필요 포트·호스트 목록이 있으면 그대로 DIRECT 화이트리스트의 시드로 쓰고, 나머지는 라이브 로그로 보강합니다.

검증 체크리스트(복사용)

  1. Clash OFF + VPN만 ON에서 내부 리소스 접속이 되는지 확인.
  2. Clash ON(시스템 프록시만)에서 동일 시나리오 재현 여부.
  3. TUN ON에서만 깨지는지 분기.
  4. 라이브 연결에서 VPN 관련 호스트·대역이 DIRECT인지 확인.
  5. 연결 전후 라우팅 테이블 덤프 비교.
  6. DNS: 내부 존 질의가 어느 리졸버로 나가는지 확인(브라우저 DoH 포함).
  7. 규칙 세트 갱신 직후에만 깨졌다면 순서·중복 RULE-SET 점검.

일반적인 연결성 질문은 FAQ와 함께 보면, 앱 설정과 규칙 YAML을 동시에 만지는 횟수를 줄일 수 있습니다.

준수: 무단 우회가 아닌 허용 범위 내 위생

⚠ 준수 알림: 기업 네트워크에서 허용되지 않은 우회·관측 회피는 법적·징계 리스크가 있습니다. 본문은 허용된 환경에서 Clash와 SSL VPN을 안정적으로 공존시키기 위한 기술 위생을 설명합니다.

보안팀이 요구하는 호스트 검사·디바이스 규정 준수가 있으면, Clash가 트래픽을 바꿀 때 검사 클라이언트가 실패해 VPN 전체가 끊길 수 있습니다. 이때는 개인 프로필 수정보다 공식 절차로 예외를 요청하는 편이 맞습니다.

맺음말

Cisco AnyConnect와 Clash의 공존 문제는 대부분 「VPN이 가야 할 패킷이 Clash 규칙·TUN·DNS 중 하나에서 다른 길로 간다」로 정리됩니다. 호스트명과 사내망 대역을 DIRECT로 명시하고, TUN과 시스템 프록시 중 실제로 쓰는 경로를 로그로 확정한 뒤, 라우팅 테이블과 DNS를 연결 전후로 비교하면 원인을 빠르게 가릅니다. 벤더가 다르더라도 같은 순서가 통합니다.

장기적으로는 규칙을 얇게 유지하고, 관측한 이름만 화이트리스트에 추가하는 편이 안전합니다. 오픈소스 메타데이터는 신뢰에 도움이 되지만, 설치 패키지 경로는 사이트 다운로드 페이지를 기준으로 두면 조직망에서도 안내가 단순해집니다.

→ Clash를 무료로 다운로드해 기업 VPN과 함께 쓸 때도 규칙·로그·DNS를 한 화면에서 맞춰 보세요. 분류는 세련될수록 좋지만, VPN 생존이 먼저일 때는 DIRECT를 과감히 쓰는 것이 비용 대비 효과가 큽니다.