越境EC担当者向けClash設定術 Amazon・Shopifyを安定運用

越境ECの通信を業務単位で設計する

Amazon、Shopify、Etsyを使う越境ECでは、商品登録、在庫同期、注文処理、広告管理、配送ラベルの発行など、複数のWebサービスを同時に扱います。管理画面の一部だけが読み込めない、認証画面でタイムアウトする、画像アップロードが途中で止まるといった小さな通信障害でも、出荷締め切りや在庫反映の遅れにつながります。Clashを導入する目的は、すべての通信を無条件にプロキシへ送ることではありません。業務に必要なドメインだけを適切な経路へ振り分け、通常の国内サービスや社内システムは直接接続に残すことが重要です。

最初に、利用するサービスを「管理画面」「API・連携」「画像や静的ファイル」「決済・配送」「社内業務」の5種類に分けます。たとえばAmazon Seller Centralの管理画面と、在庫連携ツールが呼び出すAPIでは、見えているドメインが異なる場合があります。Shopifyも管理画面、ストアの公開ページ、テーマや画像の配信元が別々です。画面を開けたからといって、CSVアップロード、商品画像の登録、Webhook、外部アプリ連携まで正常とは限りません。

業務	確認する通信	推奨する考え方
商品登録	管理画面、画像アップロード、カテゴリ情報	管理画面と関連APIを同じ安定した経路へ送る
受注処理	注文一覧、請求情報、配送ラベル	認証・決済関連を途中で経路変更しない
在庫同期	API、Webhook、連携アプリ	固定ルールとログで失敗時刻を追跡する
社内業務	会計、倉庫、チャット、国内SaaS	原則DIRECTにして遅延と誤判定を減らす

クライアントとmihomoカーネルを確認する

Clashの設定を作る前に、利用中のクライアントとカーネルを確認してください。FlClash、Clash Verge Rev、ClashXなどは設定画面を提供するクライアントであり、実際にDNS、ルール、プロキシ接続を処理するのは内蔵されたカーネルです。2026年時点では、越境ECのようにTUN、ルールセット、複数のプロトコルを使う可能性がある環境では、mihomoカーネルを利用できるクライアントのほうが設定の選択肢を確保しやすいでしょう。

画面に「Clash」と表示されていても、実際のカーネルがオリジナル版なのか、Clash Meta系なのか、mihomoなのかは別に確認します。設定画面の「コア」「Kernel」「バージョン情報」や起動ログを開き、カーネル名とバージョンを記録してください。rule-providers、TUN、Hysteria2、VLESSなどを含む購読設定を使う場合、古いカーネルでは設定の一部が無視されたり、読み込み自体に失敗したりすることがあります。

業務用の基本設定では、外部コントロールインターフェースをLANへ公開しないことも重要です。次のように、混合ポートとコントロールポートをローカルアドレスに限定します。実際のポート番号が既存のアプリや社内ツールと重なる場合は変更し、クライアント側のシステムプロキシ設定と一致させてください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: replace-with-a-long-random-secret

7890はHTTPとSOCKSをまとめて受ける混合ポートの例です。9090はクライアントがカーネルを管理するためのポートであり、ブラウザーのHTTPプロキシ欄に入力するものではありません。会社の共有Wi-Fiでallow-lan: trueにする必要がある場合も、コントロールインターフェースを0.0.0.0で公開せず、ファイアウォールと認証を必ず併用してください。

Amazon・Shopify・Etsyを分けるルール設計

ルールは上から順に照合されるため、広いルールを先に書くと、AmazonやShopify向けの指定が無効になります。たとえば先頭にGEOIP,CN,DIRECTを置くと、解決されたIPアドレスの地域判定によって、意図したサービスまで直接接続になる可能性があります。業務サービスのドメインルールを先に置き、一般通信のルールを後ろへ配置してください。

次の例では、業務用プロキシグループをEC-Work、直接接続をDIRECTとして説明しています。EC-Workという名前のプロキシグループは、実際の購読設定に存在するグループ名へ置き換えてください。Amazonの国別ドメインは販売地域によって異なるため、自社が利用するSeller CentralのURLを確認し、必要なドメインだけを追加します。

rules:
  - DOMAIN-SUFFIX,sellercentral.amazon.com,EC-Work
  - DOMAIN-SUFFIX,sellercentral.amazon.co.uk,EC-Work
  - DOMAIN-SUFFIX,sellercentral.amazon.de,EC-Work
  - DOMAIN-SUFFIX,sellercentral-japan.amazon.com,DIRECT
  - DOMAIN,admin.shopify.com,EC-Work
  - DOMAIN-SUFFIX,myshopify.com,EC-Work
  - DOMAIN-SUFFIX,shopify.com,EC-Work
  - DOMAIN-SUFFIX,shopifycdn.com,EC-Work
  - DOMAIN-SUFFIX,etsy.com,EC-Work
  - DOMAIN-SUFFIX,etsystatic.com,EC-Work
  - DOMAIN-SUFFIX,etsycdn.com,EC-Work
  - GEOIP,CN,DIRECT
  - MATCH,EC-Work

上記は構造を示す例であり、すべてのAmazon関連ドメインを網羅するものではありません。ログイン、広告、税務、配送、決済、外部アプリのドメインが別に使われる場合は、そのサービスの公式ドキュメントと実際の接続ログを照合します。特にDOMAIN-SUFFIX,amazon.comのような広すぎる指定は、購入者向けページや不要な動画・広告通信まで同じ経路へ送るため、最初から多用しないほうが管理しやすいでしょう。

DOMAIN、DOMAIN-SUFFIX、RULE-SETの使い分け

DOMAIN：admin.shopify.comのように、完全一致させたいホスト名に使います。
DOMAIN-SUFFIX：myshopify.comの配下をまとめて指定するときに使います。意図しないサブドメインまで含まれないか確認します。
RULE-SET：サービスや国・地域のドメイン一覧を外部ファイルで管理するときに使います。大規模なリストを手書きで維持する負担を減らせます。
GEOSITE、GEOIP：カーネルやデータベースの対応状況を確認して利用します。地域判定だけで業務サービスを分類しないことが大切です。
MATCH：最後に残った通信の既定経路です。業務用設定では、DIRECTにするかプロキシへ送るかを意図的に決めます。

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

設定を一度に大きく変更せず、業務の少ない時間帯に1サービスずつ検証します。ここではFlClashなどの一般的なmihomo対応クライアントを想定します。画面名はクライアントやバージョンによって異なるため、「Profiles」「設定」「覆写」「ルール」「ログ」に相当する項目を探してください。

現在の設定を保存する：購読URL、現在のYAML、手動追加したルール、プロキシグループの選択状態をバックアップします。購読URLには認証トークンが含まれることがあるため、共有フォルダーや公開リポジトリには置きません。
業務用グループを決める：遅延だけでなく、認証画面、画像アップロード、CSV処理、長時間の管理画面操作が安定するノードを選びます。url-testの自動選択を使う場合も、定期的に実業務で確認します。
ルールを追加する：Amazon、Shopify、Etsyの完全なホスト名から始め、必要に応じて関連APIや静的ファイルのドメインを追加します。広いサフィックス指定は最後に検討します。
システムプロキシを有効にする：まずブラウザーで管理画面を開き、ログイン、商品編集、画像アップロード、注文一覧の取得を順番に確認します。TUNはこの段階ではまだ有効にしません。
ログを確認する：対象ドメインがどのルールに一致し、どのプロキシグループへ送られたかを確認します。画面は表示されても、画像配信やAPIがDIRECTになっていることがあります。
必要な場合だけTUNを有効にする：在庫連携ツール、コマンドラインのCSV処理、システムプロキシを参照しないアプリまで制御したい場合に限り、TUNを追加します。

簡単な切り分けには、ブラウザーの開発者ツールとClashの接続一覧を併用します。ページ本体だけでなく、失敗したリクエストのホスト名、HTTPステータス、接続経路、DNSエラーの有無を記録します。403は権限やアクセス制御、429は頻度制限、5xxはサービス側や上流経路の障害を示すことがあります。タイムアウトだけであれば、ルールより先にDNS、ノード品質、MTU、企業ネットワークのファイアウォールを確認します。

DNSとTUNを業務環境に合わせる

ドメインルールを正しく書いても、DNS解決が不安定なら接続先を決められません。mihomoのDNS機能を使う場合は、DNSサーバーへの通信経路、Fake-IPの利用、社内ドメインの除外を確認します。社内の倉庫システムやプリンターが内部DNS名を使っているなら、すべてを公開DNSへ送る構成は避けます。外部サービスだけをプロキシ経由で解決し、社内ドメインは会社指定のDNSへ残す設計が安全です。

TUNはアプリ単位のプロキシ設定が不要になる一方、対象範囲が広くなります。まずシステムプロキシで管理画面の処理を確認し、連携ツールやターミナルなど、プロキシを参照しない通信だけTUNで補います。TUNを有効にした後は、社内VPN、リモートデスクトップ、ローカルプリンター、ファイル共有が使えるかを必ず確認してください。

出張時に業務を止めない予備設定

出張先のホテルWi-Fi、空港ネットワーク、モバイル回線では、DNS応答、UDP通信、HTTPSの接続維持時間、 captive portalの挙動が普段と異なります。自宅で安定していたノードを1つだけ頼りにするのではなく、少なくとも通常用と予備用の2つのプロキシを用意し、業務用グループから手動で切り替えられる状態にしておきます。自動選択だけに任せると、ログイン画面への到達性より短い遅延を優先して、実業務では不安定なノードが選ばれることがあります。

状況	最初に試す設定	避ける操作
ホテルWi-Fiに接続できない	Clashを一時停止し、ブラウザーで利用規約画面を完了する	認証前からTUNで全通信を捕捉する
管理画面だけタイムアウトする	予備ノードへ切り替え、DNSと接続ログを確認する	短時間に複数の国・地域へ何度も切り替える
API連携が失敗する	連携ツールのプロキシ設定とTUNの有無を確認する	ブラウザーだけで成功と判断する
社内サービスが開かない	社内ドメインとプライベートIPをDIRECTへ除外する	MATCHルールを無条件にプロキシへ送る

出張前には、商品編集画面を開く、テスト商品を下書き保存する、画像を1枚アップロードする、注文一覧を表示する、配送ラベルのプレビューを確認するという小さな検証を行います。実際の注文や決済を使う必要はありません。テスト操作が許可されないサービスでは、既存商品の編集画面や読み取り専用の一覧を使って接続経路を確認します。

認証情報を守りながら運用を続ける

越境ECのClash設定には、サブスクリプションURL、企業プロキシの認証情報、管理画面のドメイン、社内ネットワーク情報が集まりやすくなります。YAMLをチャットへ貼り付ける場合は、購読トークン、Bearerトークン、パスワード、Cookie、秘密鍵を必ず削除します。ログを共有するときも、URLのクエリ、リクエストヘッダー、メールアドレス、注文番号が含まれていないか確認してください。

ルールの変更履歴も残しておくと、業務停止時の復旧が速くなります。変更日、変更者、追加したドメイン、使用したプロキシ、テスト結果を簡単に記録します。購読設定を更新した後にルールが消えた場合は、購読ファイルへ直接追記するのではなく、クライアントのオーバーライド、Mixin、またはローカルルール機能で分離してください。購読更新で上書きされる場所に手書き設定を保存すると、次回更新時に再び消える可能性があります。

月に一度、Amazon、Shopify、Etsyの管理画面とAPI連携を確認する。
ノード変更後は、商品画像、CSV、注文一覧など実際に使う処理を小さくテストする。
mihomoやクライアントを更新する前に、現在のYAMLとオーバーライドを保存する。
使わなくなったドメインルール、プロキシ、認証情報を削除する。
認証失敗が続く場合は、同じ操作を繰り返さず、サービス側の通知とセキュリティ履歴を確認する。

安定した越境EC運用では、プロキシの速度だけでなく、同じ条件で再現できること、業務通信と私的通信を分けられること、失敗時に直接接続へ戻せることが重要です。まずシステムプロキシと限定的なドメインルールから始め、ログで不足を確認してからDNS、ルールセット、TUNへ段階的に広げると、Amazon、Shopify、Etsyを使う現場でも変更範囲を管理しやすくなります。