해외 이커머스 운영에서 Clash 라우팅이 필요한 이유
Amazon 상품 관리 화면과 Shopify Admin은 단순한 웹페이지처럼 보이지만 실제 운영 중에는 로그인, 상품 이미지, 주문 데이터, 결제 설정, 분석 대시보드, 외부 앱 API가 동시에 여러 호스트와 통신합니다. 한국에서 평소에는 빠르던 화면이 해외 출장 중 갑자기 느려지거나, 로그인은 되었는데 주문 목록만 비어 보이는 이유도 여기에 있습니다. 브라우저 한 탭의 문제처럼 보여도 실제로는 DNS 응답, TLS 연결, CDN 경로, 계정 인증 세션이 서로 다른 네트워크 조건을 만납니다.
특히 셀러가 공항 와이파이, 호텔 네트워크, 현지 유심, 회사 VPN을 번갈아 사용하면 출발 IP와 DNS 위치가 계속 바뀝니다. Amazon은 로그인과 판매자 콘솔에서 보안 검사를 추가할 수 있고, Shopify는 관리자 페이지와 스토어 운영용 외부 서비스가 서로 다른 도메인을 사용할 수 있습니다. 이때 무작정 모든 트래픽을 프록시로 보내면 한국의 결제 서비스나 사내 시스템까지 불필요하게 우회되어 오히려 업무가 느려질 수 있습니다. 핵심은 “해외 이커머스 업무 트래픽만 같은 정책 그룹으로 묶고, 나머지는 기존 경로를 유지하는 것”입니다.
sellercentral, amazon, shopify, admin 같은 호스트를 검색하세요. 같은 페이지를 새로 고침했는데도 연결마다 정책 그룹이 달라진다면 노드 속도보다 규칙 분류와 DNS부터 점검해야 합니다.
이 글의 기준은 Clash Verge Rev, Clash Verge, Mihomo Party처럼 Mihomo 계열 코어를 사용하는 클라이언트입니다. 메뉴 이름은 클라이언트마다 다를 수 있지만 프로필, 규칙 모드, 시스템 프록시, TUN, DNS라는 다섯 가지 개념은 대체로 같습니다. 구형 Clash for Windows를 사용하는 경우에도 원리는 비슷하지만, 오래된 코어가 최신 YAML 필드를 인식하지 못하면 먼저 지원되는 코어로 교체하는 편이 안전합니다.
Amazon·Shopify 도메인과 업무별 정책 그룹 나누기
시작부터 DOMAIN-SUFFIX,amazon.com,PROXY처럼 넓은 규칙 하나를 복사하는 것은 권장하지 않습니다. Amazon은 상품 관리, 판매자 센터, 이미지 CDN, 광고, 결제 보고서가 서로 다른 호스트를 사용할 수 있으며, 국가별 Amazon 사이트도 .com, .co.jp, .co.uk처럼 달라집니다. Shopify 역시 관리자 화면의 기본 도메인과 실제 상점 도메인, 앱 프록시, 외부 분석 서비스가 같은 접미사에 속하지 않을 수 있습니다.
- Amazon 판매자 영역: 사용 중인 국가의 Seller Central 호스트와 로그인 리다이렉트 도메인을 연결 로그에서 확인합니다.
- Amazon 상품·주문 데이터: 상품 편집, 주문 처리, 재고 동기화 중 새로 나타나는 API 호스트를 별도로 기록합니다.
- Shopify 관리자:
admin.shopify.com과 스토어별 관리자 요청을 구분하고, 실제 요청이 어떤 정책을 타는지 확인합니다. - 상점 공개 페이지: 고객용 스토어 도메인은 관리자 트래픽과 목적이 다르므로 필요하면 별도 그룹으로 분리합니다.
- 외부 앱과 결제 서비스: ERP, 광고, 배송, 세금 계산 앱은 Amazon이나 Shopify가 아닌 제3자 도메인을 사용하므로 로그를 보고 필요한 호스트만 추가합니다.
업무 목적별로는 ECOMMERCE_ADMIN, ECOMMERCE_STORE, ECOMMERCE_API처럼 세 그룹을 두는 방식이 관리하기 쉽습니다. 처음에는 관리자와 로그인 관련 호스트를 하나로 묶고, 화면이 안정된 뒤 외부 앱과 공개 스토어를 분리하세요. 규칙을 한 번에 많이 추가하면 무엇이 문제를 해결했는지 알 수 없고, 구독 프로필이 갱신될 때 수동 규칙이 사라지는지도 놓치기 쉽습니다.
| 업무 영역 | 권장 정책 | 점검 포인트 |
|---|---|---|
| Seller Central·Shopify Admin | ECOMMERCE_ADMIN | 로그인 리다이렉트와 관리자 API가 같은 출구를 사용하는지 확인 |
| 상품 이미지·정적 파일 | ECOMMERCE_STORE 또는 별도 CDN 그룹 | CDN 호스트가 관리자 도메인과 다른지 확인 |
| ERP·배송·광고 연동 | ECOMMERCE_API | 앱 제공업체의 실제 API 도메인을 연결 로그에서 확인 |
| 국내 은행·사내 시스템 | DIRECT 또는 회사 정책 그룹 | 해외 이커머스 규칙에 실수로 포함되지 않았는지 확인 |
중요: Amazon이나 Shopify의 모든 하위 도메인을 추측해 넣기보다, 실제 실패 시점의 로그에서 확인한 호스트를 기준으로 좁게 추가하세요. 지나치게 넓은 규칙은 계정 보안 확인, 국내 결제, 사내 도구까지 같은 출구로 보내 운영 범위를 불필요하게 키울 수 있습니다.
시스템 프록시와 TUN 모드: 브라우저 밖의 이커머스 도구까지 확인하기
브라우저에서 Shopify 관리자 페이지가 열리는데 데스크톱 ERP나 재고 동기화 프로그램은 실패한다면, 시스템 프록시와 TUN 모드의 차이를 먼저 봐야 합니다. 일반적인 시스템 프록시는 HTTP 또는 HTTPS 프록시를 이해하는 애플리케이션에 효과적입니다. 반면 일부 프로그램은 자체 네트워크 라이브러리를 사용해 시스템 프록시를 무시합니다. 이런 경우 Clash 화면에는 브라우저 연결만 보이고, 실제로 실패한 재고 프로그램의 연결은 전혀 기록되지 않을 수 있습니다.
TUN 모드는 운영체제의 가상 네트워크 인터페이스를 통해 더 넓은 트래픽을 Clash로 전달합니다. Amazon 주문 CSV를 내려받는 브라우저뿐 아니라, 로컬 자동화 도구가 HTTPS API를 호출하거나 배송 라벨 프로그램이 외부 서비스에 접속할 때도 동일한 규칙을 적용할 수 있다는 장점이 있습니다. 다만 모든 트래픽을 잡는 만큼 DNS 설정, 권한 승인, 다른 VPN과의 충돌이 중요해집니다.
- 기존 VPN을 잠시 끕니다. 기업 VPN, WireGuard, 다른 Clash 포크가 동시에 터널을 만들면 기본 경로와 DNS가 서로 덮어쓸 수 있습니다.
- Clash 코어가 실행 중인지 확인합니다. TUN 버튼만 켜져 있고 Mihomo 코어가 중지된 상태라면 트래픽은 정상적으로 처리되지 않습니다.
- 관리자 권한과 가상 인터페이스 승인을 확인합니다. Windows와 macOS 모두 첫 활성화 때 권한 창이나 시스템 확장 승인이 나타날 수 있습니다.
- 테스트 도메인을 하나씩 엽니다. Amazon 관리자, Shopify 관리자, 공개 스토어, 국내 업무 사이트 순서로 접속하고 연결 로그의 정책명을 비교합니다.
- 업무 도구를 마지막에 테스트합니다. 브라우저만 성공한 뒤 전체가 해결됐다고 판단하지 말고 ERP, 재고, 배송, 광고 도구의 실제 동기화 작업까지 확인합니다.
TUN을 켠 뒤 국내 사이트가 느려졌다면 TUN을 바로 끄기보다 규칙 모드와 DNS를 함께 확인하세요. GEOIP,KR,DIRECT 같은 규칙이 조직 환경에 맞는지, 사내 도메인이 국내 IP로 해석되는지, 마지막에 있는 MATCH 규칙이 모든 요청을 예상하지 못한 그룹으로 보내고 있지 않은지 살펴봐야 합니다. 해외 출장 중에는 현지 호텔 포털이나 공항 인증 페이지가 프록시를 통해 열리지 않는 경우도 있으므로, 해당 네트워크에 처음 연결할 때는 캡티브 포털 인증을 먼저 끝내는 편이 좋습니다.
DNS와 출구 IP 점검: 속도보다 계정 안정성이 먼저
해외 이커머스에서 DNS는 단순히 “빠른 서버를 고르는 기능”이 아닙니다. 같은 도메인이 지역에 따라 다른 IP와 CDN을 반환할 수 있고, DNS 요청은 직접 보내면서 실제 HTTPS 연결은 프록시로 보내는 식으로 경로가 갈라질 수도 있습니다. 이 상태에서는 화면 일부만 늦거나 로그인 후 API 호출만 실패하는 등 원인을 찾기 어려운 증상이 생깁니다.
Clash의 DNS 설정에서 fake-ip와 redir-host 중 무엇을 사용할지는 클라이언트와 네트워크 환경에 따라 달라집니다. fake-ip은 도메인 기반 규칙을 일관되게 적용하기 쉽지만, 일부 보안 프로그램이나 오래된 앱이 가상 IP를 싫어할 수 있습니다. 반대로 redir-host는 호환성이 나은 경우가 있지만 DNS 재해석과 규칙 매칭이 복잡해질 수 있습니다. 설정을 바꿀 때는 여러 옵션을 한꺼번에 바꾸지 말고, 하나의 프로필을 복사한 뒤 Amazon 로그인과 Shopify 상품 저장을 각각 재현하세요.
- DNS 모드 변경 후에는 Clash 캐시와 브라우저 DNS 캐시를 함께 비웁니다.
- 같은 도메인이 매번 다른 지역 IP를 반환하는지 확인하고, 특정 국가 서버를 무조건 고정하지 않습니다.
- 프록시 DNS와 로컬 DNS가 섞이지 않도록 설정한 뒤 연결 로그와 실제 IP를 비교합니다.
- 관리자 로그인 직후 출구 IP가 바뀌지 않도록 한 세션에서는 같은 정책 그룹을 유지합니다.
출구 IP는 웹사이트의 IP 확인 페이지 하나만 보고 판단하지 말고, 실제 업무 세션의 정책과 함께 기록해야 합니다. 호텔 와이파이에서 한국 노드로 로그인했다가 자동 그룹이 일본 노드로 바뀌면 Amazon의 보안 검사가 다시 나타날 수 있습니다. 이것이 곧 계정 차단을 의미하는 것은 아니지만, 짧은 시간에 국가와 ASN이 반복해서 바뀌면 추가 인증이나 세션 종료가 발생할 가능성이 커집니다. 따라서 url-test가 빠른 노드를 계속 교체하는 환경보다, 관리자 업무에는 안정적인 select 그룹을 두고 필요할 때만 수동으로 바꾸는 구성이 더 예측 가능합니다.
느린 관리자 페이지와 로그인 실패를 진단하는 순서
로그에서 정책 매칭부터 확인하기
첫 번째 질문은 “어느 노드가 가장 빠른가?”가 아니라 “각 요청이 어느 정책 그룹을 탔는가?”여야 합니다. Shopify 관리 화면을 새로 고침하면서 admin.shopify.com, 스토어 도메인, 이미지 호스트, 앱 API를 각각 필터링합니다. Amazon도 로그인 페이지, Seller Central 본문, 주문 API, 이미지 CDN이 같은 정책으로 처리되는지 구분해 보세요. 일부 요청이 DIRECT로 빠지고 일부만 프록시를 타면, 먼저 규칙 우선순위를 고친 뒤 노드 성능을 비교해야 합니다.
로그인은 되지만 작업 중 세션이 끊기면 어떻게 하나요?
자동 정책 그룹이 짧은 간격으로 노드를 교체하는지 확인하세요. 관리자 페이지는 장시간 세션과 여러 API 요청을 사용하므로, 페이지를 여는 순간과 저장 버튼을 누르는 순간 출구 국가나 IP가 달라지면 재인증이 발생할 수 있습니다. 이커머스 관리자용 그룹은 안정적인 노드를 수동 선택하고, 일정 시간 동안 고정한 뒤 다시 테스트하는 것이 좋습니다. 브라우저 쿠키를 먼저 삭제하기보다 Clash 연결 로그와 IP 변화를 기록해야 불필요한 재로그인을 줄일 수 있습니다.
공개 스토어는 빠른데 관리자 화면만 느린 이유는 무엇인가요?
공개 스토어는 방문자용 CDN에서 정적 파일을 제공하지만, 관리자 화면은 인증 API와 데이터 요청을 반복합니다. 두 경로가 서로 다른 호스트와 리전에 연결되므로 공개 페이지의 속도만으로 관리자 성능을 판단할 수 없습니다. 관리자 호스트를 별도 정책 그룹으로 분리하고, 로그인·상품 저장·주문 조회를 각각 실행해 어느 단계에서 지연이 생기는지 확인하세요. DNS 모드와 TUN을 변경했다면 변경 전 프로필과 결과를 비교하는 것도 중요합니다.
TUN을 켰는데 ERP나 재고 프로그램이 여전히 연결되지 않습니다.
해당 프로그램이 TUN 트래픽에 포함되는지, 운영체제 방화벽이나 프로그램 자체의 인증서 검사가 연결을 차단하는지 확인합니다. Clash 로그에 관련 요청이 전혀 없다면 규칙 문제가 아니라 우회하지 않는 네트워크 경로일 수 있습니다. 반대로 로그에 요청이 보이지만 TLS 오류가 난다면 DNS, 시스템 시간, 다른 보안 소프트웨어의 HTTPS 검사, API 공급자의 IP 허용 목록을 순서대로 점검하세요. TUN을 여러 번 껐다 켜기보다 하나의 테스트 프로필에서 원인을 좁히는 편이 안전합니다.
해외 이커머스 업무에서는 단순한 브라우저 프록시 확장 프로그램이 관리자와 외부 앱, DNS 정책을 함께 관리하지 못하고, 일부 상용 VPN은 자동 서버 전환 때문에 로그인 세션의 출구 IP가 자주 바뀌는 한계가 있습니다. Clash V.CORE는 Mihomo 기반 규칙, TUN, DNS, 연결 로그와 정책 그룹을 한 흐름에서 조정할 수 있어 Amazon·Shopify 관리자 트래픽을 업무 목적별로 분리하고 재현 가능한 설정을 남기기 좋습니다. 출장지에서 노드와 규칙을 직접 통제해야 하거나 브라우저 밖의 ERP까지 같은 기준으로 점검해야 한다면, 현재 환경에 맞는 Clash V.CORE를 다운로드해 허용된 네트워크와 계정 정책 안에서 이 가이드를 단계별로 적용해 보세요.