Preface
For cross-border sellers, a connection problem is rarely just an inconvenience. A stalled Seller Central page can interrupt listing edits, inventory checks, or a time-sensitive response to a buyer. A Shopify admin session may fail to load while you are updating products or reviewing orders. Unstable access can also make campaign checks and routine account maintenance harder to complete reliably.
Clash is a traffic-routing client, not an internet service or a guarantee of access. It can direct selected traffic through a proxy group, leave other traffic on your normal connection, and make it easier to switch between available nodes. Whether a particular service is reachable still depends on your network, the proxy provider, the destination’s security controls, and your account’s region and policies. Use a stable, authorized connection and follow the terms that apply to your seller account.
This guide shows how to organize Clash rules for Amazon Seller Central and Shopify admin, test the result without changing unrelated traffic, and prepare a practical backup for travel. The examples use Mihomo-compatible YAML syntax; menu names differ between Clash Verge, Clash Verge Rev, and other clients, but the routing principles are similar.
The Goal
Route seller-management traffic predictably, keep rules easy to inspect, and retain a tested fallback when your primary network or proxy node is unavailable.
1Plan a Safer Routing Strategy
Start by deciding what you need to route and why. Sellers do not all work from the same country or use the same marketplace, account region, or proxy service. A rule set copied from another person may send traffic through an unexpected location or fail to match the domains your browser actually uses. Before editing a profile, write down the marketplace pages and Shopify admin pages you use, the network on which you will test, and the proxy group you intend to select.
For many sellers, a dedicated proxy group is easier to manage than a single hard-coded node. The group can contain several provider nodes, allowing you to choose a suitable option or use a health-checked selection strategy if your configuration supports it. Give the group a clear name, such as Seller-Work, and confirm that its name matches the rule target exactly. A rule pointing to a group that does not exist can prevent a configuration from loading or lead to unexpected routing.
Choose the Right Mode
In Rule mode, Clash evaluates the rules in order and applies the first matching action. This is generally the most controlled option for separating seller tools from ordinary browsing. Global mode sends broadly more traffic through the selected proxy and can be useful as a short diagnostic, but it is not a substitute for deliberate rules. Direct mode bypasses proxy routing; use it only when it is appropriate for your network and the service you are accessing.
Keep seller traffic in its own logical group rather than assigning every commercial site to a broad rule such as DOMAIN-KEYWORD,shop. Broad keyword matches can capture unrelated websites and make troubleshooting harder. Also avoid routing entire cloud-provider networks by IP range unless you know exactly what those ranges contain: hosted services share infrastructure, and IP rules can affect unrelated traffic.
Before You Edit
Duplicate or export your current profile first. Subscription updates can overwrite local changes, so keep a recoverable copy and use your client’s supported override or merge mechanism when available.
Add Narrow, Reviewable Domain Rules
The following example illustrates a small set of domain rules. It assumes your configuration already contains a proxy group named Seller-Work. Place these entries above broad rules such as GEOIP or MATCH, and keep them in the existing rules: list. Do not create a second rules: key in the same YAML file.
These examples are not a complete list of every regional Amazon marketplace, API, login provider, payment service, or storefront domain. A seller may use a country-specific Amazon host, a separate identity page, or a custom Shopify storefront domain. Do not assume that a single suffix covers every request involved in signing in or managing a store. Instead, use Clash’s connection or rule-matching view while loading the exact pages you need, note the domains involved, and add only well-understood domains that are necessary for your workflow.
In particular, a custom storefront domain is not automatically identifiable as a Shopify domain just because its site runs on Shopify. If you add a rule for the custom domain, confirm whether you want that visitor traffic proxied too; admin access and customer-facing storefront access are separate requirements. A narrower rule set is easier to audit and less likely to alter personal browsing or other business applications.
2Configure and Test Amazon and Shopify Access
Make one change at a time. First confirm that the profile parses successfully and that the Seller-Work group appears in your client. Select a known working node manually for the initial test rather than relying on automatic selection. Check that the operating system proxy or TUN mode is enabled if your chosen client and workflow require it. TUN mode can capture more applications than the system proxy, but it also affects more traffic and may require administrator permission.
Next, open the client’s connections or logs panel and visit the relevant seller page in a fresh browser tab. Look for the request’s domain, matched rule, and selected policy group. A useful test verifies all three: the request reached Clash, the intended seller rule matched, and the selected group chose the expected node. A page that loads successfully is not, by itself, proof that every request followed the same route; a page may combine content from multiple domains.
| Test | What to verify | What to avoid concluding |
|---|---|---|
| Seller Central page load | The browser request appears in Clash and matches the intended rule. | One loaded page proves all Amazon regions and sign-in services are covered. |
| Shopify admin page load | Admin-related requests use the expected policy group and selected node. | A custom storefront domain must use the same route as the admin. |
| Routine browsing | Unrelated sites still follow their normal rules. | Global mode is a good permanent fix for a narrow seller-platform issue. |
| Node switch | New requests use the newly selected node after the switch. | An existing login session or open connection changes route immediately. |
When a site is partially loaded, check the browser’s developer tools or the Clash connection list for blocked or failed requests. Login, account protection, images, scripts, and API calls may use different hosts. Add a missing domain only after confirming its purpose and its relationship to the page. If the site presents an additional verification step, complete it through the service’s normal process. Do not repeatedly switch locations to try to bypass account security checks; unexpected changes in network location may cause extra verification or temporary restrictions.
Keep Browser Sessions Stable
Changing nodes or routing policies while an account session is active can interrupt requests and make the browser appear to be signed out. When changing a policy, finish or save any work, close the affected tab, make the change, and then open a new tab for a controlled test. If a page remains in a loading loop, clear site data only when appropriate and be prepared to sign in again using the account’s normal authentication process. Avoid deleting all browser data as a first step; that can remove useful sessions and make recovery more complicated.
Use one browser profile for seller work if practical. Keep its extensions limited to trusted tools, and avoid testing several proxy routes in multiple tabs at once. A consistent browser profile, stable node, and documented rule set make it much easier to distinguish a Clash routing issue from a browser, account, or service-side problem.
Account and Data Safety
Use authorized access methods, protect credentials and authentication codes, and avoid public or untrusted nodes for seller accounts. A proxy does not replace account security, and an IP address alone cannot guarantee that a service will accept a session.
3Troubleshoot Failures and Prepare a Travel Backup
When access fails, resist the urge to rewrite the entire profile. Identify which layer is failing: the local connection, Clash itself, the selected node, DNS resolution, the domain rule, the browser session, or the destination service. Compare a normal site with the seller page, then check whether the affected request appears in Clash. If it does not appear, the client may not be capturing that application’s traffic. If it appears but matches a broad rule, rule order or domain coverage is more likely to be the issue.
| Symptom | Checks to make | Practical next step |
|---|---|---|
| Seller page times out | Check node availability, rule match, and whether other websites load. | Test one known working node and inspect the failed request in Clash. |
| Sign-in page loads, admin does not | Check whether login and admin requests use different domains. | Inspect the connection list and add only confirmed domains. |
| Repeated verification prompt | Check for frequent node or network changes and browser session issues. | Use a consistent connection and follow the platform’s recovery prompts. |
| Only some resources fail | Look for additional API, script, or content hosts that failed to match. | Review failed requests individually rather than adding broad keyword rules. |
| Configuration will not load | Check YAML indentation, duplicate keys, and the proxy-group name. | Restore the backup, validate the profile, then reapply one change at a time. |
DNS problems can look like routing problems. If a host fails to resolve, confirm that Clash’s DNS settings are enabled and that the profile’s resolver configuration is valid for your environment. Do not paste a generic DNS block over an existing subscription without checking how the client handles profile updates, fake-IP settings, and exclusions. After a DNS change, restart or reload the profile as recommended by the client, then repeat the same controlled test.
Build a Travel-Ready Backup
Travel adds variables that a desktop-only test may not reveal: hotel Wi-Fi portals, captive networks, mobile hotspots, blocked ports, and unstable local connections. Before departure, verify that Clash starts correctly, the profile is current, the seller group contains more than one usable option if your provider offers alternatives, and you know how to switch to a backup node. Keep a copy of your profile or supported configuration backup in a secure location, but do not expose subscription URLs, passwords, or authentication tokens in public notes.
Test the backup connection before relying on it for order management. A quick checklist is to connect to the travel network, complete any captive-portal sign-in, start Clash, confirm the selected profile and group, and load the seller pages you actually use. If the primary connection fails, switch one variable at a time: first the local network if available, then the proxy node, then the relevant rule or DNS setting. This sequence helps you identify the cause instead of making several changes that are difficult to reverse.
Keep an independent fallback that does not depend on the same laptop or Wi-Fi connection, such as a secure mobile hotspot where available. Protect the device with a screen lock, avoid saving seller credentials on shared computers, and sign out of account sessions on devices you do not control. If a connection remains unreliable, use the platform’s official support and account-recovery options rather than trying unverified configurations under time pressure.
A dependable seller setup is usually modest: a readable rule list, a clearly named proxy group, a tested primary node, and a backup you have actually tried. Review the configuration after provider or profile updates, because group names, node availability, and routing behavior can change. Keep a short record of the last working setup and the checks you performed; it makes the next troubleshooting session faster and reduces the temptation to apply broad, risky changes.