해외 이커머스 업무에서 Clash가 필요한 이유
해외 판매자는 하루에도 여러 종류의 웹 서비스를 오갑니다. Amazon Seller Central에서 주문·재고·반품을 확인하고, Shopify 관리자에서 상품과 결제를 관리하며, 별도의 광고 대시보드와 가격 조사 도구에서 데이터를 확인합니다. 문제는 이 서비스들이 모두 같은 네트워크 경로를 사용하지 않는다는 점입니다. 판매자 페이지는 로그인과 세션 유지가 중요하고, 상품 조사 사이트는 여러 국가의 CDN과 검색 서버를 호출하며, 광고 도구는 짧은 시간에 많은 API 요청을 발생시킵니다.
그래서 “아마존 판매자 페이지가 계속 로딩된다”, “쇼피파이 로그인은 됐지만 관리자 화면이 빈 페이지로 나온다”, “광고 리포트 다운로드 중 연결이 끊긴다”와 같은 증상이 나타날 수 있습니다. 단순히 모든 트래픽을 하나의 노드로 보내면 일시적으로 해결되는 것처럼 보여도, 업무 서비스와 일반 웹사이트가 한 경로에 몰려 속도와 안정성이 함께 떨어질 수 있습니다. Clash 분할 설정의 목적은 특정 서비스를 무조건 우회하는 데 있지 않습니다. 허용된 네트워크 환경에서 업무별 트래픽을 구분하고, 필요한 연결만 일관된 정책으로 처리해 로그인 세션과 관리 작업을 안정적으로 유지하는 데 있습니다.
사용 전 확인: 회사·공유 오피스·쇼핑몰 운영 계정의 보안 정책과 각 서비스 약관을 먼저 확인하세요. 이 글은 합법적으로 사용할 수 있는 프록시 환경에서 Clash와 Mihomo의 라우팅을 점검하는 기술 안내이며, 계정 지역 제한이나 플랫폼 정책을 우회하는 방법을 설명하지 않습니다.
Amazon·Shopify 업무 트래픽을 먼저 나누기
설정을 시작하기 전에 어떤 업무가 어느 도메인과 연결되는지 정리해야 합니다. “Amazon 전체”, “Shopify 전체”처럼 서비스 이름만 보고 규칙을 만들면 실제 로그인 서버, 정적 파일 서버, 결제·분석 API가 서로 다른 호스트로 분산되어 일부 화면만 실패할 수 있습니다. 먼저 정상적인 업무 세션을 하나 재현하고 Clash의 연결 로그를 확인하는 방식이 가장 정확합니다.
| 업무 그룹 | 주요 목적 | 확인할 트래픽 | 권장 정책 |
|---|---|---|---|
| 스토어 관리 | 주문, 상품, 재고, 반품, 고객 문의 | 판매자 관리자 도메인, 인증·API 호스트, CDN | 전용 프록시 그룹으로 일관되게 처리 |
| 상품 조사 | 검색 결과, 경쟁 상품, 가격·리뷰 확인 | 검색 서비스, 이미지 CDN, 분석 페이지 | 조사 전용 그룹 또는 업무용 그룹 사용 |
| 광고 확인 | 캠페인, 키워드, 리포트, 예산 확인 | 광고 관리자, 리포트 API, 파일 다운로드 호스트 | 로그인과 다운로드가 같은 출구를 보도록 구성 |
| 일반 트래픽 | 뉴스, 메일, 국내 웹사이트, 개인 브라우징 | 업무와 관계없는 일반 도메인 | DIRECT 또는 별도 기본 그룹 |
Amazon Seller Central은 국가별 판매자 페이지와 계정 인증 경로가 다를 수 있습니다. 미국 스토어를 관리한다고 해서 모든 관련 연결이 하나의 고정된 호스트로만 발생한다고 가정하면 안 됩니다. Shopify 역시 관리자 도메인, 스토어 도메인, 결제·앱 연동 서버가 분리될 수 있습니다. 특히 Shopify 앱이나 외부 재고 관리 도구를 함께 사용하는 경우에는 앱이 호출하는 API가 Shopify 기본 도메인과 다를 수 있으므로, 첫 설정에서 연결 로그를 기록해 두는 것이 좋습니다.
도메인을 찾을 때는 DOMAIN-SUFFIX를 무조건 넓게 적용하지 마세요. 예를 들어 브랜드 이름이 포함된 모든 호스트를 하나의 그룹으로 보내면 이미지·동영상·고객지원·분석 트래픽까지 예상하지 못한 경로를 사용할 수 있습니다. 가능한 경우 실제로 확인한 FQDN을 DOMAIN 규칙으로 시작하고, 같은 서비스의 하위 도메인이 반복해서 확인될 때만 범위를 단계적으로 넓히는 편이 안전합니다.
클라이언트와 프로필을 업무에 맞게 준비하기
Windows에서는 Clash Verge Rev나 Mihomo Party처럼 Mihomo 커널을 지원하는 클라이언트가 프로필·규칙·TUN을 함께 관리하기 편합니다. macOS에서는 Clash Verge Rev, Mihomo 계열 GUI, 환경에 맞는 네이티브 클라이언트를 선택할 수 있습니다. Android는 모바일 업무가 필요할 때 Clash Meta 계열 앱을 고려할 수 있지만, 배터리 절약 기능이 백그라운드 연결을 종료하지 않는지 별도로 확인해야 합니다.
중요한 것은 클라이언트 이름보다 현재 구독이 사용하는 규칙 문법과 커널이 서로 맞는지입니다. 오래된 Clash 설정을 Mihomo 클라이언트에 그대로 넣을 때는 지원되지 않는 필드, 프록시 그룹 이름, DNS 옵션이 있는지 확인하세요. 프로필을 가져온 뒤에는 즉시 원본을 덮어쓰지 말고, 복사본을 만들어 업무용 규칙을 추가하는 방식이 좋습니다. 구독이 갱신될 때 수동으로 넣은 규칙이 사라지는 구조라면, 클라이언트의 모듈·스크립트·오버라이드 기능을 사용하거나 별도의 관리 파일로 보관해야 합니다.
운영 팁: 업무용 그룹의 이름을 STORE, RESEARCH, ADS처럼 명확하게 정하면 연결 로그를 볼 때 규칙 오매칭을 빠르게 찾을 수 있습니다. 노드 이름만 보고 고르기보다 지연 시간, 반복적인 세션 끊김, 업무 시간대의 안정성을 함께 기록하세요.
Clash에서 업무별 분할 규칙 적용하기
아래 절차는 특정 서비스의 공식 도메인을 임의로 추측하지 않고, 실제 사용 로그를 기준으로 규칙을 구성하는 흐름입니다. 메뉴 이름은 Clash Verge, Clash Verge Rev, Mihomo Party 버전에 따라 조금 다를 수 있지만, 프로필 가져오기·규칙 편집·연결 로그 확인이라는 순서는 대부분 같습니다.
- 업무를 분리합니다. Amazon 주문 관리, Shopify 상품 관리, 상품 조사, 광고 리포트처럼 업무를 나누고 각 업무에 필요한 브라우저 탭이나 앱을 정리합니다.
- 프로필을 백업합니다. 현재 정상 작동하는 YAML을 복사해 업무용 파일을 만들고, 구독 URL·외부 컨트롤러 주소·비밀번호가 다른 사람에게 노출되지 않도록 보관합니다.
- 전용 프록시 그룹을 확인합니다. 안정적인 노드를 하나 고르거나
url-test기반 그룹을 사용합니다. 로그인 중에는 자동 노드 전환이 세션을 끊을 수 있으므로, 중요한 작업에서는 수동 선택이 더 예측 가능합니다. - 연결 로그를 켭니다. Amazon Seller Central에 로그인하고 주문 화면, 상품 편집, 광고 리포트를 차례로 열면서 발생한 도메인과 현재 매칭된 규칙을 기록합니다.
- 규칙을 좁게 추가합니다. 확인한 호스트에 업무 그룹을 지정하고, 처음부터
DOMAIN-KEYWORD,amazon처럼 넓은 규칙을 사용하지 않습니다. Shopify 앱처럼 별도 API를 사용하는 경우에는 해당 호스트를 로그에서 추가로 확인합니다. - 규칙 순서를 검토합니다. 업무용 규칙이 일반적인
GEOIP,GEOSITE,MATCH보다 위에 있는지 확인합니다. 규칙은 위에서 아래로 먼저 일치하는 항목이 적용되는 경우가 많습니다. - 기능별로 테스트합니다. 로그인, 주문 목록, 상품 저장, 이미지 업로드, 광고 리포트 다운로드를 각각 실행하고, 실패한 단계의 로그에서 호스트·DNS 결과·프록시 그룹을 비교합니다.
- 안정화 후에만 TUN을 검토합니다. 브라우저와 업무 앱이 시스템 프록시를 따르지 않을 때 TUN을 켭니다. 활성화 전에는 다른 VPN·보안 프로그램·가상 네트워크 어댑터와 충돌하지 않는지 확인합니다.
예시 규칙의 형태는 다음과 같습니다. 실제 도메인은 자신의 연결 로그와 서비스 공식 문서를 기준으로 바꾸어야 합니다.
rules:
- DOMAIN,seller.example.com,STORE
- DOMAIN,admin.example-shop.com,STORE
- DOMAIN,ads.example.com,ADS
- DOMAIN-SUFFIX,cdn.example-shop.com,STORE
- GEOIP,PRIVATE,DIRECT
- MATCH,DIRECT위 예시에서 중요한 부분은 특정 서비스명을 포함하는 모든 도메인을 한꺼번에 묶지 않고, 업무에 필요한 호스트만 등록했다는 점입니다. GEOIP,PRIVATE,DIRECT는 로컬 네트워크 주소가 프록시로 잘못 들어가는 것을 줄이는 데 도움이 될 수 있지만, 회사 내부 DNS나 사설 API를 사용하는 환경에서는 예외가 필요할 수 있습니다. 규칙을 추가한 뒤에는 프로필을 다시 적용하고, 기존 연결을 종료한 다음 새 세션으로 테스트하세요. 이미 열린 브라우저 세션은 이전 DNS 결과와 쿠키 상태를 계속 사용할 수 있습니다.
DNS·TUN·계정 보안을 함께 점검하기
이커머스 관리자 화면의 문제를 모두 프록시 노드 탓으로 돌리면 해결이 늦어집니다. DNS 모드가 바뀌면서 특정 호스트가 잘못된 주소로 해석되거나, fake-ip와 로컬 앱의 호환성이 맞지 않아 로그인 리디렉션이 실패할 수도 있습니다. 한 번에 DNS 모드, TUN, 노드, 규칙을 모두 바꾸지 말고 현재 설정을 기록한 뒤 한 요소씩 변경하세요. 같은 브라우저에서 일반 웹은 정상인데 관리자 페이지만 빈 화면이라면 개발자 도구의 네트워크 오류와 Clash 연결 로그를 함께 비교하는 것이 유용합니다.
TUN은 브라우저뿐 아니라 시스템 프록시를 무시하는 데스크톱 앱, 터미널, 일부 동기화 프로그램의 트래픽까지 잡을 수 있다는 장점이 있습니다. 반면 모든 트래픽이 가상 인터페이스를 거치므로, 로컬 프린터·NAS·회계 프로그램·회사 내부망이 영향을 받을 수 있습니다. 모든 트래픽을 프록시로 보내는 것이 항상 좋은 것은 아닙니다. 사설 주소, 로컬 도메인, 사내 시스템은 예외 규칙으로 DIRECT 처리하고, TUN을 켠 뒤에는 주문 입력과 파일 업로드가 실제로 정상인지 다시 확인해야 합니다.
판매자 계정은 네트워크 설정만큼 보안 관리도 중요합니다. Amazon과 Shopify의 로그인 세션을 여러 국가의 노드로 짧은 시간 안에 바꾸면 추가 인증이나 보안 알림이 발생할 수 있습니다. 업무별로 노드를 자주 교체하기보다 신뢰할 수 있는 출구를 정하고, 2단계 인증·복구 코드·권한이 제한된 직원 계정을 사용하세요. 구독 URL에는 개인 식별 토큰이 포함될 수 있으므로 YAML을 공개 저장소나 채팅방에 올리지 말고, 외부 컨트롤러 포트와 API 비밀번호도 인터넷에 노출하지 않아야 합니다.
세션 문제를 줄이는 방법: Amazon 또는 Shopify에서 주문을 저장하거나 광고 예산을 변경하는 중에는 노드를 수동으로 바꾸지 마세요. 먼저 작업을 저장하고, 연결이 안정된 뒤 필요한 경우에만 프로필이나 노드를 변경합니다.
자주 발생하는 오류와 장기 운영 방법
로그인 화면이 반복되는 경우
로그인 페이지가 계속 처음으로 돌아가면 인증 호스트와 관리자 호스트가 서로 다른 정책을 적용받는지 확인합니다. 인증 도메인은 DIRECT, 관리자 도메인은 프록시로 나뉘면 브라우저가 받은 쿠키와 리디렉션 요청의 네트워크 위치가 달라질 수 있습니다. 연결 로그에서 로그인 버튼을 누른 순간 새로 나타난 도메인을 확인하고, 동일한 인증 흐름이 같은 그룹을 사용하도록 규칙을 조정하세요. 시크릿 창에서 테스트하면 오래된 쿠키나 확장 프로그램의 영향을 분리하는 데 도움이 됩니다.
관리자 화면이 빈 페이지인 경우
빈 화면은 HTML 본문은 열렸지만 JavaScript 번들, API 응답, 이미지 CDN 중 하나가 차단된 상황일 수 있습니다. 브라우저 개발자 도구에서 403, 401, ERR_CONNECTION_RESET, CORS 관련 메시지를 구분하고 Clash 로그에서 같은 시각의 호스트를 찾습니다. 정적 CDN을 업무 API와 무조건 같은 그룹으로 보낼 필요는 없지만, 로그인 직후 로드되는 필수 JS 파일이 다른 경로로 빠지면 화면이 완성되지 않을 수 있습니다.
광고 리포트 다운로드가 실패하는 경우
광고 리포트는 관리자 페이지와 별도로 파일 저장 CDN이나 임시 다운로드 주소를 사용할 수 있습니다. 리포트 생성은 성공했는데 파일 저장만 실패한다면, 다운로드 버튼을 누른 직후 생성된 호스트를 확인하세요. 임시 URL은 일정 시간이 지나면 만료될 수 있으므로 같은 링크를 반복해서 테스트하지 말고 새 리포트를 생성해 재현합니다. 대용량 CSV가 중간에 끊긴다면 노드의 장시간 연결 품질, 브라우저 확장 프로그램, 회사 방화벽의 파일 검사 기능도 함께 점검해야 합니다.
장기 운영에서는 설정을 “한 번 완성하고 끝나는 파일”로 생각하지 않는 것이 좋습니다. Shopify 앱을 추가하거나 Amazon의 지역별 관리 페이지가 변경되면 새로운 호스트가 나타날 수 있고, 구독 갱신으로 규칙 순서나 그룹 이름이 바뀔 수도 있습니다. 월 1회 정도 업무별 로그인·주문 조회·상품 저장·리포트 다운로드를 짧게 점검하고, 변경 전후의 연결 로그를 보관하세요. 문제가 생겼을 때는 전체 설정을 초기화하기보다 최근 변경 사항, 실패한 기능, 매칭 규칙, 사용 노드, DNS 모드를 다섯 줄로 기록하면 원인 추적이 훨씬 빨라집니다.
일반적인 무료 프록시 앱이나 브라우저 확장 프로그램은 Amazon과 Shopify의 업무 흐름처럼 여러 도메인과 장시간 세션이 섞인 환경에서 규칙을 세밀하게 나누기 어렵고, TUN·DNS·로그 확인 기능이 부족한 경우가 많습니다. 반대로 Clash 공식 사이트는 Mihomo 기반 클라이언트와 프로필 구조를 비교하면서 업무별 그룹, 규칙 순서, 연결 로그를 단계적으로 점검할 수 있어 스토어 관리와 광고 확인을 한 설정 안에서 정리하기 좋습니다. 특정 서비스에 대한 무리한 우회를 권하는 대신 안정적인 운영과 보안 점검에 초점을 맞춘 자료를 찾고 있다면, 필요한 클라이언트를 먼저 다운로드해 시작해 보세요.