この記事で分かること

越境ECの担当者にとって、Amazon Seller CentralやShopify Adminを安定して開けることは、単なる閲覧性の問題ではありません。受注の確認、在庫調整、商品情報の更新、広告予算の変更、顧客対応など、毎日の業務が管理画面への接続に依存しています。特定の地域からアクセスするとログイン画面だけが表示されない、二段階認証の途中で止まる、画像やレポートの読み込みが極端に遅い、といった症状が起きると、注文処理の遅延や広告運用の機会損失につながります。

本稿では、Clashを越境EC業務に組み込む際の考え方を、EC担当者の目線で整理します。AmazonとShopifyを同じ経路に固定するのではなく、管理画面、決済、社内ツール、配送会社、国内向けサービスを用途別に分け、必要な通信だけを適切なプロキシグループへ送る方法が中心です。さらに、出張先やホテルのWi-Fiでの切り替え、複数アカウントを扱う場合の注意点、実際のIP環境を確認する手順まで説明します。

設定例はClash Verge RevやMihomo系クライアントを想定していますが、基本的な考え方はClash for Windows、ClashX、Clash for Androidなどにも応用できます。重要なのは、特定のドメイン一覧を盲目的に追加することではなく、Clashのログを見ながら、実際に業務で使われるホストと経路を確認することです。

越境ECで必要になる通信を整理する

最初に行うべきことは、AmazonやShopifyだけを見てルールを作らないことです。管理画面を開くと、認証、画像配信、分析、広告、決済、外部アプリなど、複数のホストへ同時に接続されます。トップページが表示できても、レポート画面や商品画像だけが失敗する場合は、補助ドメインの一部が別の経路へ流れている可能性があります。

業務端末で利用するサービスを、次のように分けて考えると設定しやすくなります。ここでいう「プロキシ」は、契約しているサービスのポリシーと利用地域の法令を守ったうえで、安定した通信経路を選ぶためのものです。地域制限や販売者アカウントの規約を回避する目的で、無理に所在地を偽装する運用は避けてください。

用途 代表的な通信 基本方針
Amazon管理 Seller Central、商品登録、注文・広告レポート 安定した固定グループへ送る
Shopify管理 管理画面、ストア設定、アプリ連携 Amazonと同一または別の安定グループを選ぶ
決済・認証 二段階認証、決済サービス、社内SSO 無用な経路変更を避け、信頼できる回線を使う
国内業務 社内Wiki、勤怠、配送会社、銀行サイト 原則DIRECT、社内ルールを優先する
分析・広告 広告管理、アクセス解析、タグ管理 管理画面と同じ経路で挙動を確認する

AmazonとShopifyを一律に「海外サイト」としてまとめると、国内の配送管理や社内ログインまでプロキシへ送ってしまうことがあります。その結果、認証通知が遅れたり、社内システムのアクセス元制限に引っかかったりするため、サービス単位だけでなく業務単位でも分けることが大切です。

Amazon・Shopify向けのルール設計

Clashのルール設定では、まずプロファイル全体の既定動作を確認します。最後のMATCHがDIRECTになっている場合、ルールに登録していないホストはすべて直接接続になります。逆にMATCHがプロキシグループになっていると、社内サービスや国内サイトまで迂回する可能性があります。越境EC用のプロファイルでは、利用範囲を明確にしてから最後のMATCHを決めてください。

AmazonとShopifyについては、最初から大量のサブドメインを登録するより、ログに表示された接続先を観察する方法が安全です。Seller Centralを開いて注文一覧、商品編集、広告レポートの順に操作し、Shopifyでも管理画面、商品登録、注文詳細、アプリ画面を一つずつ確認します。各操作の直後にClashの接続ログを見れば、どのホストが必要だったのかを把握できます。

  • DOMAIN-SUFFIXは、同一サービスの複数サブドメインをまとめたい場合に使います。ただし、広すぎる親ドメインを指定すると、別用途の通信まで含まれることがあります。
  • DOMAINは、特定の完全修飾ドメインだけを対象にしたい場合に向いています。決済や認証など、影響範囲を絞りたい通信に適しています。
  • DOMAIN-KEYWORDは便利ですが、無関係なホスト名に同じ文字列が含まれる可能性があります。業務端末では、ログで一致先を確認してから使うべきです。
  • IP-CIDRは、CDNやクラウドのアドレス変更に弱い場合があります。ECサービスでは、IPアドレスの固定登録を最初の選択肢にしない方が保守しやすいでしょう。

たとえば、設定の考え方は次のようになります。実際のドメイン名やグループ名は、利用中のサービス、購読プロファイル、Clashクライアントの記法に合わせて調整してください。

rules:
  - DOMAIN-SUFFIX,example-amazon-host.com,EC-Work
  - DOMAIN-SUFFIX,example-shopify-host.com,EC-Work
  - DOMAIN-SUFFIX,company-internal.example,DIRECT
  - MATCH,DIRECT

この例をそのまま実運用に貼り付けるのではなく、Clashのログに出た実ホストへ置き換えます。Shopifyの外部アプリやAmazonの広告画面など、追加ホストがDIRECTへ落ちている場合は、その通信だけを個別に登録します。ルールを追加した後は、ブラウザのキャッシュだけに頼らず、いったんログアウトして再ログインし、注文一覧やレポートの読み込みまで確認してください。

TIP：AmazonやShopifyの管理画面を開いたままルールを大量に変更すると、既存のKeep-Alive接続が古い経路に残ることがあります。ルール変更後は対象タブを閉じ、Clashの接続を確認してから新しいタブで開き直すと、切り替え結果を判断しやすくなります。

実際に設定して確認する手順

ここでは、Clash Verge Revを使ってEC業務用の経路を作る流れを説明します。画面名はバージョンによって異なる場合がありますが、基本は「プロファイルを分ける」「グループを選ぶ」「ルールを確認する」「サービスを実測する」の四段階です。最初からTUNを有効にするのではなく、ブラウザのシステムプロキシで動作を確認すると、問題の範囲を狭められます。

  1. 業務用プロファイルを複製する。日常閲覧用の設定を直接変更せず、EC運用専用のプロファイル名を付けます。担当者が複数いる場合は、変更日時と変更理由も社内に記録します。
  2. プロキシグループを選ぶ。速度だけでなく、接続の安定性、タイムアウトの頻度、必要な地域の経路を比較します。一度の遅延テストだけで決めず、管理画面を数回開いた結果を見ます。
  3. システムプロキシを有効にする。ブラウザでAmazonとShopifyを開き、ログイン、注文一覧、商品編集、レポートの主要操作を実施します。認証アプリや社内ツールの通信まで変わっていないかも確認します。
  4. Clashのログを確認する。アクセスした時刻とホスト名を照合し、意図したルールやグループにマッチしているか確認します。赤いエラーだけでなく、DIRECTに落ちた接続も見てください。
  5. 必要な場合だけTUNを試す。ブラウザは動くのに、在庫同期ツールやデスクトップアプリだけが失敗する場合に限り検討します。企業VPN、EDR、Docker、仮想マシンと競合することがあるため、導入前に停止・復元方法を確認します。

EC担当者が最も見落としやすいのは、ブラウザ本体と補助ツールでプロキシの扱いが異なる点です。ブラウザはシステムプロキシを読んでいても、在庫連携ツール、CSV自動取得スクリプト、広告レポートのAPIクライアントは環境変数や独自設定を参照することがあります。CLIを使う場合は、たとえば次のように現在の環境変数を確認します。

env | grep -i proxy
curl -I https://管理対象のホスト名

WindowsではPowerShell、macOSやLinuxではターミナルを使い、Clashの混合ポート番号と実際のプロキシ設定が一致しているか確認します。環境変数を設定した後に起動済みのアプリへ反映されないこともあるため、対象アプリを完全に終了してから再起動してください。API連携が必要な場合は、サービス側の利用規約、認証方式、アクセス頻度も確認し、管理画面の自動操作を無制限に行わないようにします。

出張時の切り替えとIP環境の確認

出張先では、ホテル、空港、展示会場、テザリングなど、ネットワークが短時間で変わります。接続が変わるたびにプロファイルを作り直すのではなく、通常用と出張用の二つ程度に分け、切り替え後に必ず実測する運用が現実的です。ホテルの認証ページが必要な場合は、最初にプロキシを無効にしてWi-Fiの利用規約画面を通し、その後Clashを有効にします。認証前からTUNを有効にすると、ログイン画面が表示されないことがあります。

出張先から管理画面へ入る前に、IP確認サイトや業務で許可された確認ページを使い、表示されるグローバルIP、国・地域、IPv4とIPv6の状態を確認します。IPアドレスが想定外の地域になっている場合は、ノードの切り替え、IPv6の経路、ブラウザのDNS、別VPNの同時利用を順に調べます。IPだけでアカウントの安全性を判断することはできませんが、急な地域変化を把握する手掛かりにはなります。

Amazonや決済サービスでは、短時間に異なる国や地域からログインすると、追加認証やセキュリティ確認が発生する場合があります。担当者が出張する際は、管理者やアカウント所有者へ事前に共有し、利用する端末、期間、接続経路を記録しておくと、異常ログインと誤認された際に説明しやすくなります。共有アカウントを複数人で使い回すより、可能であれば個別権限と監査ログを整備する方が安全です。

また、IPが安定していても、DNSだけが別経路へ流れると、表示地域や認証先が不一致になることがあります。Clash側のDNSモード、ブラウザの安全なDNS、OSのIPv6設定を同時に変更すると原因が分からなくなるため、設定は一項目ずつ変更してください。障害が発生した時刻、ネットワーク名、選択グループ、IP確認結果、Clashログを残しておけば、担当者交代後も再現性のある改善ができます。

運用で起きやすい問題と改善策

「Amazonは開くがShopifyのアプリ画面だけ遅い」「注文一覧は表示されるが広告レポートが失敗する」という症状では、サービス全体を別ノードへ移す前に、Clashログで追加ホストを確認します。管理画面は複数のAPIやCDNを利用するため、メインページのドメインだけ登録しても全機能は安定しません。一方、すべてを広いワイルドカードでプロキシへ送ると、不要な通信、社内アクセス、決済通知まで巻き込む危険があります。

  • ログインだけ失敗する場合：認証ホスト、二段階認証、ブラウザのCookie、端末時刻を確認します。プロキシグループを頻繁に変更した直後なら、セッションを破棄して再ログインします。
  • 画像やCSVだけ失敗する場合：CDN、ファイル配信、ダウンロード用ホストが別ルールになっていないか確認します。大容量ファイルでは速度より接続の持続性を優先します。
  • 担当者によって結果が違う場合：購読プロファイル、Clashコア、DNS、ブラウザ拡張、OSのプロキシ設定を比較します。設定ファイルの共有だけでは、端末側の差異を解消できません。
  • 社内サイトまで遅くなった場合：社内ドメイン、プライベートIP、会社VPNの経路をDIRECTまたは社内指定の経路へ戻します。TUNを使っている場合は、ルートとDNSの競合も確認します。

設定の完成度は、特定の日に一度成功したかではなく、通常業務を再現できるかで判断します。朝のログイン、注文確認、商品編集、在庫同期、広告確認、CSV出力という一連の作業を、平日と出張先の双方で試してください。成功した設定はエクスポートして保管し、変更前のバックアップも残します。購読情報には認証情報が含まれる場合があるため、共有ストレージへ置くときはアクセス権を限定してください。

単純なVPNアプリだけで運用すると、アプリごとの除外やAmazon・Shopifyの補助ホストの確認が難しく、国内の社内サービスまで一括して経路変更されることがあります。反対に、Clashはルール、ログ、プロキシグループ、DIRECT、必要に応じたTUNを組み合わせ、EC業務の通信を説明可能な形で分けられます。サービス別の切り替えや出張先でのIP確認を重視するなら、この可視性と柔軟性によって、障害時の切り分けから復旧までを短くできます。

Clash を無料でダウンロードして、快適なネット体験を →