越境ECの接続をClashで扱う前に決めること
AmazonセラーセントラルやShopify管理画面にアクセスできないとき、すぐにノードを切り替えるのではなく、まず「どの端末から、どの業務画面へ、どのネットワーク経路で接続するか」を整理しましょう。Clashは接続をルールに従って直結またはプロキシ経由に振り分けるツールです。AmazonやShopifyのアカウント認証、地域制限、権限、本人確認を変更するものではありません。
店舗運営用の通信では、商品登録、在庫更新、注文確認、広告管理などの作業を安定して続けられることが重要です。接続元が頻繁に変わると、サービス側の追加認証やセキュリティ確認が発生する場合があります。出張中にアクセスできないからといって、国や地域を偽装して制限を回避しようとするのではなく、利用地域とアカウントの要件を確認し、組織の承認したネットワークと端末を使ってください。
- 業務端末を分ける：可能なら店舗運営用のブラウザーやOSユーザーを用意し、個人の閲覧環境とCookie、拡張機能、保存済み認証情報を混在させないようにします。
- 接続元の方針を決める：社内ネットワークから直結するのか、会社が承認したプロキシ出口を使うのかを管理者と確認します。通信先ごとに方針が異なる場合は、その根拠と変更担当者も記録します。
- アカウント保護を優先する：多要素認証を有効にし、サブスクリプションURL、認証コード、セッショントークン、注文情報をログやスクリーンショットに残さないでください。
Amazon・Shopifyのドメインをルールにする際の注意
Amazonセラーセントラルはマーケットプレイスや地域によって入口のURLが異なり、ログイン後に別のホスト名、認証画面、商品画像、広告、レポート用APIへ接続することがあります。Shopifyも管理画面のURLだけで処理が完結するとは限りません。管理画面、ストア固有のホスト名、認証、アプリ連携など複数の接続先が使われる可能性があります。画面に表示されたURLだけを見て、必要な通信先をすべて推測することはできません。
そのため、サービス名を含む大きなドメインサフィックスを見つけて一括でプロキシへ送る方法は避けましょう。一般向けのストア閲覧、社内ツール、ログイン、決済関連の通信まで同じ扱いになり、意図しない範囲へ影響することがあります。また、AmazonやShopifyが利用するドメイン構成は変更される可能性があり、古いルールが永久に有効とは限りません。
- 完全一致：特定のホスト名だけを対象にしたい場合に向きます。対象が一つでも、認証後に別ホストへ移るなら追加の確認が必要です。
- サフィックス一致：親ドメインとサブドメインをまとめて扱えますが、対象範囲が広がります。登録前に、その範囲に含まれる業務と無関係な通信がないか確認してください。
- IPベースのルール：クラウドやCDNのIPは共有・変更されることがあります。固定IPを前提にした広範なルールは、誤判定や保守負担の原因になります。
- フォールバック：個別ルールに一致しない接続の出力先を明確にします。末尾の包括ルールが先に置かれていると、後続の例外ルールは評価されません。
対象ドメインを確認するには、まず通常の業務操作を行い、Clashの接続履歴やログで実際に観測されたホスト名と選択されたポリシーを記録します。ログに認証情報やURLのクエリ文字列が表示される場合は、共有前に伏せてください。知らないホストを見つけても、即座に広いサフィックスで許可せず、業務上の役割と組織のセキュリティ方針を確認してから判断します。
直結とプロキシの使い分けを業務単位で考える
ClashのDIRECTは、クライアントのルール判定を通った接続を、選択したプロキシノードではなく端末の通常のネットワーク経路で外部へ接続する指定です。必ずしも「安全な接続」や「会社の固定IP」を意味しません。一方、プロキシグループを指定しても、選択中のノードの出口IPが固定であるとは限りません。出口の安定性や許可リストへの登録が必要な業務では、提供元や管理者に仕様を確認してください。
次のYAMLは、ルールの置き場所を示すための構造例です。admin.example.invalidと業務接続は説明用の仮名であり、AmazonやShopifyの実在ドメイン、推奨ポリシー名ではありません。実際のホスト名とプロキシグループ名は、自分の接続ログと設定に照らして置き換えます。サブスクリプションから生成された設定を直接編集すると、更新時に変更が失われる場合があるため、クライアントのオーバーライドやマージ機能を使ってください。
mode: rule
rules:
- DOMAIN,admin.example.invalid,業務接続
- MATCH,DIRECTこの例は、指定した一つのホストを「業務接続」へ送り、その他を直結する構成です。末尾のMATCH,DIRECTは説明を簡潔にするための例にすぎず、すべての環境で適切とは限りません。既存設定のMATCHを置き換える前に、社内の標準ルール、LAN向け例外、DNS設定、他の業務通信への影響を確認してください。プロキシグループ名は、proxy-groupsに定義された名前と一字一句一致させます。
選択基準を記録する
- 会社の指定ネットワークや許可済み出口を使う必要がある業務画面は、管理者が承認した経路に固定します。
- 社内の在庫管理、プリンター、管理画面などは、社内ネットワークに必要な経路を確認し、安易に外部プロキシへ送らないようにします。
- ルールに一致しない接続の扱いを明示し、意図しない通信が想定外の経路へ流れないか接続履歴で確認します。
- 一時的な検証でモードやポリシーを変更した場合は、作業後に通常の設定へ戻し、変更内容と理由を記録します。
実務で試す手順：設定、接続確認、ロールバック
いきなり複数のドメインやポリシーを変更すると、ログイン失敗の原因を特定しにくくなります。まず現在の設定をバックアップし、対象を一つの管理画面と一つの端末に絞って検証します。画面名はClashクライアントによって異なりますが、設定プロファイル、接続履歴、ログ、プロキシグループの順に確認すると、原因を段階的に追えます。
- 作業条件を記録する：OS、Clashクライアントとコアのバージョン、利用ネットワーク、現在のモード、選択中のポリシーをメモします。サブスクリプションURLや認証コードは記録に含めません。
- 変更前の状態を確認する：ブラウザーで対象画面を開き、ログインできるか、どのホスト名が接続履歴に出るか、各接続にどのルールとポリシーが適用されたかを確認します。画面が表示されない場合は、まずネットワーク自体とサービス側の障害情報も確認します。
- 小さなルールを追加する：業務上必要と確認できたホストだけを対象にし、広いサフィックスルールは後回しにします。既存の包括ルールより前に配置し、ルールモードで動作していることを確認します。
- 新しい接続で再試験する：ブラウザーの既存タブや接続プールには変更前の状態が残ることがあります。対象タブを閉じて新しく開き、ログイン、商品情報の保存、注文一覧の表示など必要な操作を少数のテストデータで確認します。
- ログと画面の両方を見る：接続履歴で一致ルールと出力ポリシーを確認し、ブラウザーに認証エラー、タイムアウト、証明書警告がないか確認します。証明書警告を無視して業務を続けないでください。
- 変更を確定するか戻す：結果が安定し、組織の方針にも合う場合だけ変更を残します。失敗した場合は追加ルールを外し、バックアップした設定に戻してから、DNS、プロキシ出口、サービス側の認証状態を個別に切り分けます。
出張・ネットワーク変更に備える
出張先やホテル、空港、モバイル回線では、ポータル認証、DNS、IPv6、社内VPN、Wi-Fiの分離設定などが普段と異なることがあります。Clashのノードを変更すれば必ず解決するわけではありません。出発前に会社が許可した接続方法、必要な二要素認証の手段、緊急連絡先、アカウント復旧手順を確認し、現地で初めて設定を試す状況を避けましょう。
- 事前に更新する：クライアントとコアの互換性、設定の有効期限、利用予定ノードの接続可否を確認します。大切な作業の直前に大規模な設定変更やメジャー更新を行わないでください。
- 認証手段を確保する：会社の承認に従って認証アプリや予備コードを安全に準備します。予備コードをClashの設定ファイル、共有ログ、ブラウザーのメモ欄へ保存しないでください。
- ホテル等のWi-Fiを確認する：利用規約とログイン画面を確認してから業務通信を開始します。ポータル認証前は接続できないサービスがあるため、先にClashのルールを増やすのではなく、ネットワーク認証が完了しているか確認します。
- 障害時の代替手段を決める：モバイル回線や会社指定のVPNなど、許可された代替ネットワークを事前に確認します。無断で個人向けプロキシへ切り替えたり、アカウント共有で回避したりしないでください。
出張後は一時的なモード変更、TUNの有効化、システムプロキシの設定が残っていないか点検します。Clashを終了しただけでは、すべてのOS設定が必ず期待どおりに戻るとは限りません。社内ネットワークへのアクセス、通常のブラウジング、業務画面の接続を一つずつ確認し、不要なルールや例外を整理してください。
よくある質問
Shopify管理画面だけプロキシにすれば、関連する通信もすべて切り替わりますか？
必ずしもそうではありません。管理画面を開く際に認証、アプリ、APIなど別のホストへ接続することがあります。接続履歴で実際の通信先を確認し、必要性と組織の方針を確認したうえで、対象を個別に追加してください。根拠なく広いドメイン範囲をプロキシへ送るのは避けましょう。
Amazonセラーセントラルにログインできない場合、まずノードを変更すべきですか？
先にネットワーク接続、サービス側の障害、アカウントの認証状態、多要素認証、ブラウザーの時刻やCookieを確認します。接続ログに通信がある場合は、一致したルールと出力先も確認してください。頻繁な接続元変更が追加確認につながる可能性もあるため、ノードを無作為に切り替えないでください。
店舗運営用のルールを追加するなら、TUNを有効にする必要がありますか？
ブラウザーがシステムプロキシ設定に従い、必要な通信が正常に処理されるなら、ルール設定のためだけにTUNを有効にする必要はありません。TUNは取り込む通信の範囲を広げる機能で、ルールの出力先そのものを決める機能ではありません。必要性がある場合に限り、権限や他のVPNとの競合も含めて確認してください。
社内のIP許可リストに登録した接続元をClashで維持できますか？
Clashの設定だけでは、プロキシ出口のIPが固定されるとは限りません。許可リストを使う業務では、会社が承認した固定出口の有無、経路の管理主体、障害時の連絡先を確認してください。現在の接続元IPを画面上で確認しただけで、将来も同じIPになると判断しないようにしましょう。