Clash E-Commerce Setup: Reliable Amazon, Shopify & Etsy Access

Define the business traffic you actually need to route

E-commerce work depends on more than opening a storefront in a browser. A seller may use Amazon Seller Central, Shopify Admin, Etsy Shop Manager, advertising dashboards, payment services, inventory tools, customer-support platforms, analytics pages, and video or image storage during the same working session. If every connection is sent through one proxy, unrelated traffic becomes slower and troubleshooting becomes difficult. If nothing is routed, a dashboard may time out, fail to load reports, or reject a session when the current network cannot reach a required service reliably.

A practical Clash design starts by separating business traffic from ordinary traffic. Use proxy rules for the domains and applications that need a selected route, while keeping local websites, software updates, banking services, and other low-risk destinations direct where appropriate. This is usually more stable than enabling a global proxy mode for an entire computer. It also reduces unnecessary bandwidth usage and prevents a personal browser tab or background service from consuming the same connection needed for order processing.

Choose the right Clash mode for the job

Rule mode is the normal starting point for e-commerce work. It allows specific business domains to use a business proxy group while other traffic follows a direct rule. Global mode can be useful for a short diagnostic test: if a dashboard works globally but fails in rule mode, the rules or missing dependencies need attention. It is not usually the best permanent setting because it sends every application through the same path.

System proxy mode is often sufficient for Chrome, Edge, Firefox, and other applications that honor the operating system’s HTTP or SOCKS settings. TUN mode is more comprehensive and can capture applications that ignore the system proxy, such as some desktop inventory tools, command-line utilities, or embedded app containers. TUN also changes DNS and routing behavior, so enable it only after the basic browser workflow is stable.

Build a business policy group and a direct fallback

A reliable configuration should provide more than one usable outbound option. Create a business group containing a preferred node, an automatic latency-tested group, and, if available, a backup node in a different region or provider. Keep a direct policy available for services that must use the local network. A backup does not mean choosing a random server whenever the first one becomes slow; it means defining a controlled switch that can be tested before an outage.

Names differ between subscriptions. One provider may expose a group named PROXY, another Node Select, and another a regional group such as Singapore or Japan. Do not paste a rule referring to a policy group that does not exist. First open the configuration’s proxy-group list and identify the exact group names. A rule that points to a missing group may be ignored, rejected, or fall through to an unexpected policy.

mode: rule
mixed-port: 7890
allow-lan: false
log-level: info

proxy-groups:
  - name: ECOMMERCE
    type: select
    proxies:
      - Business Auto
      - Business Primary
      - Business Backup
      - DIRECT

  - name: Business Auto
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - node-a
      - node-b
      - node-c

rules:
  - DOMAIN-SUFFIX,amazon.com,ECOMMERCE
  - DOMAIN-SUFFIX,amazonaws.com,ECOMMERCE
  - DOMAIN-SUFFIX,shopify.com,ECOMMERCE
  - DOMAIN-SUFFIX,etsy.com,ECOMMERCE
  - MATCH,DIRECT

This sample is a structure rather than a universal drop-in file. The node names must be replaced with names from the imported configuration. The test URL is only a connectivity probe; a low probe latency does not prove that Amazon, Shopify, or Etsy will accept the session. In a subscription-managed configuration, local overrides may be safer than editing the provider-generated YAML directly, because a later subscription update can overwrite manual changes.

Use specific rules before broad rules

Clash evaluates rules from top to bottom. A broad rule placed too early can capture traffic intended for another policy. For example, a general regional rule or an existing GEOIP rule may match an IP before a later domain rule is evaluated. Put your confirmed business rules above broad geographic and final-match rules, then inspect the connection log to confirm the selected policy.

• Use DOMAIN for an exact hostname when only one known endpoint should use the business group.
• Use DOMAIN-SUFFIX for a controlled family of subdomains, such as a verified service domain and its subdomains.
• Use DOMAIN-KEYWORD sparingly because a keyword can match unrelated domains and create unexpected proxy traffic.
• Use RULE-SET when maintaining a larger domain collection, but check the provider, update interval, and compatibility with the mihomo core.
• Keep MATCH,DIRECT or another deliberate final rule so unmatched traffic does not silently follow an accidental policy.

Do not add every hostname found in a browser log without understanding its role. A static asset host may be safe to access directly, while an authentication or API endpoint may require the same route as the dashboard. Conversely, proxying payment, tax, or local logistics services through a foreign exit can cause a security review or an inaccurate regional result. Treat each addition as a controlled change.

Hands-on test: validate a complete listing and order workflow

Testing only the home page is not enough. A dashboard can load its initial HTML while API requests, image uploads, report downloads, or embedded applications fail later. Perform the following test with a small, low-risk listing or a draft product before changing a live catalog. Record the selected policy, approximate response time, and any error message at each stage.

1. Prepare a clean session. Open a private browser window or use a separate browser profile. Disable unrelated extensions that alter headers, scripts, or location information. Keep the Clash connection log visible so each request can be associated with a policy.
2. Confirm the local proxy state. Check that only one Clash-compatible client is running, the expected mixed port such as 127.0.0.1:7890 is listening, and the system proxy points to the active client. Two clients competing for the same port can produce intermittent failures.
3. Open the seller dashboard. Sign in and wait for the main page, navigation panels, notifications, and account information to finish loading. If the page is blank, inspect failed requests rather than immediately changing the node.
4. Test a draft listing. Open the product editor, save a harmless title or draft field, upload a small image, and confirm that the save request succeeds. This checks API access, upload connections, and session continuity.
5. Test order operations. Open an order detail page, download or preview a document if required, and verify that the order list can paginate. Do not alter fulfillment status merely for a connectivity test.
6. Test advertising and reports separately. Advertising consoles and report services may use different hosts. Load an overview page, apply a narrow date filter, and download a small report if the account permits it.
7. Switch to the backup policy. Change only the ECOMMERCE group, repeat the most important read-only actions, and note whether sign-in or risk checks are triggered. A backup that has never been tested is not a dependable fallback.
8. Return unrelated traffic to its intended route. Open a local courier or accounting page and confirm in the Clash log that it uses DIRECT if that is the intended design. This prevents a successful business test from hiding an overly broad rule.

When a request fails, look at the connection entry’s hostname, matched rule, policy group, outbound node, and error type. A timeout before the TLS handshake points toward reachability, DNS, or the selected node. A successful connection followed by an HTTP 403 or account challenge may be an application security decision rather than a Clash routing error. Do not repeatedly refresh a seller dashboard during an investigation; excessive retries can create a rate-limit or risk-control event.

Handle DNS, TUN, and browser-session details

Many apparent dashboard failures are caused by inconsistent DNS behavior. The browser may resolve a hostname through the operating system while the proxy node uses another resolver, producing a route that does not match the intended exit region. With mihomo, DNS settings, fake-IP behavior, redirection, and TUN options can interact. Avoid changing all DNS fields at once. First determine whether the failure occurs in system proxy mode, then test the same workflow in TUN mode if the application does not honor the proxy.

If TUN is enabled, confirm that the virtual interface is actually running and that the client has the required administrator or VPN permission. Check whether IPv6 is being captured consistently. A browser may prefer IPv6 while the proxy path only handles IPv4, resulting in long waits or a reset connection. Temporarily disabling IPv6 for diagnosis can help isolate the issue, but it should not be treated as a permanent fix without understanding the operating system and network environment.

Browser sessions also have their own state. Switching between distant exit locations during one login can invalidate cookies or trigger a new verification step. For normal operations, select one stable business policy and keep it for the duration of a session. Do not use a proxy to disguise an account’s legitimate location or bypass a marketplace’s terms; routing should improve connectivity and operational consistency, not defeat platform security controls.

Protect control ports and business credentials

A local Clash controller such as 127.0.0.1:9090 should not be exposed to the public internet. Keep allow-lan: false unless another device genuinely needs access, and configure a strong controller secret when the client supports it. An exposed external controller can allow someone to inspect connections, change proxy policies, or interfere with the local network.

Treat subscription URLs, session cookies, marketplace credentials, and exported YAML files as sensitive data. A subscription URL may contain a bearer token. Remove or mask it before sharing logs or support screenshots. Avoid placing the complete URL in a public issue, team chat, screen recording, or cloud document with broad permissions. If a token is exposed, revoke or regenerate it through the subscription provider.

Prepare a travel fallback without changing everything

Business travel introduces new Wi-Fi portals, captive networks, hotel DNS, mobile hotspots, and restrictive outbound policies. The objective is not to build a complicated emergency configuration at the airport. Prepare a second connection path while the primary network is healthy, then keep the fallback simple enough to diagnose offline.

• Export or preserve the working configuration. Record the active proxy group, mixed port, TUN state, DNS mode, and important local overrides. Do not rely on memory after the original client has been closed.
• Test a second node or provider. Verify that it can load the seller dashboard and at least one read-only order page. Latency tests alone are insufficient.
• Keep a direct mode available. Hotel login pages and captive portals often need direct access. Turn off the system proxy or select DIRECT temporarily to complete network authentication, then restore the business policy.
• Carry an independent network option. A mobile hotspot or another trusted connection can distinguish a local Wi-Fi problem from a proxy or account problem.
• Use one stable travel exit. Avoid switching countries repeatedly while processing orders, signing in, or responding to customer messages.
• Do not store credentials in configuration files. Keep marketplace passwords in a password manager and use multi-factor authentication supported by the platform.

A fallback should also include a communication plan. If a report download fails, record the time, network name, active policy, node, matched rule, and error message. If the dashboard works but a specific business action is rejected, stop retrying and contact the marketplace or payment provider through its official support channel. Network routing cannot correct an account permission, billing, inventory, or policy issue.

With this structure, Clash becomes a controlled routing layer rather than a single switch that affects the entire computer. Amazon, Shopify, and Etsy workflows receive a predictable path, local services remain available through their intended route, and travel failures can be isolated without repeatedly changing every setting. Keep the rules narrow, verify the actual hostnames in the connection log, and test the complete business workflow before relying on the configuration during a high-pressure sales or fulfillment period.