先明确目标：改善连接，不改变账号使用边界
跨境电商后台的“访问不稳定”，可能表现为登录页反复加载、订单列表空白、图片或报表请求超时，也可能只是某个办公网络无法连接。先把问题拆成几类：本地网络是否可用、目标域名是否进入 Clash、规则选中的出站是否正常，以及浏览器会话或平台服务本身是否异常。仅凭页面打不开，不能直接判断是节点问题。
Clash 负责接收流量并按配置转发，不会修复账号权限、平台风控或浏览器 Cookie，也不能保证某个出口一定适合特定平台。卖家应遵守 Amazon、Shopify 及所在地区的适用规则，不用代理绕过身份验证、地区限制或平台安全措施。尽量使用稳定、可解释的办公网络；避免在短时间内频繁切换国家或地区出口，以免触发额外验证。
- 选品与市场调研：浏览公开页面时，先确认当地网络能否正常访问，再决定是否需要代理。不要把访问公开商品页的规则直接套到卖家后台。
- 订单与客服处理：优先保持固定网络与固定出站策略，减少登录期间切换节点、模式和 DNS 设置。
- 出差办公：先验证酒店或移动网络，再检查代理连接；必要时使用企业批准的网络方案，并保留平台账号的多因素验证。
规则模式与直连分流：按用途管理后台流量
日常使用建议从规则模式开始。规则模式根据列表从上到下匹配连接，并将命中的流量交给代理组、节点或 DIRECT。它既不意味着所有连接都走代理，也不意味着所有平台域名都应设置为直连。全局模式适合短时间对照出站路径，不宜作为长期排障的唯一方法；直连模式可用于确认本地网络能否访问目标，但不能证明账号或平台服务没有问题。
Amazon 的卖家入口会因国家或地区、账号类型和访问路径而异，Shopify 后台也可能调用多个主机名与内容服务。浏览器开发者工具或 Clash 连接记录中看到的域名，应先核实其用途；不要照抄来源不明的“全站域名清单”，更不要把一个主域名后缀直接设为代理或直连。后缀规则可能同时影响后台、商店前台、静态资源及其他子域名。
先用精确域名，确认后再扩大范围
如果连接记录确认某个请求确实属于后台登录流程，可以对已核实的完整主机名使用 DOMAIN 规则。例如，只有在自己的访问记录确实出现该主机名时，才考虑对 admin.shopify.com 添加精确规则。Amazon 入口同样应以当前账号实际使用的区域地址和连接记录为依据，不要假设一个示例域名覆盖所有卖家站点。
规则中的策略名称必须与现有 proxy-groups 完全一致。以下片段仅说明排列方式，不是可直接导入的完整配置；请把示例域名和“办公代理”替换为已确认的主机名与实际策略。若本地直连符合平台使用要求，可将精确规则指向 DIRECT；若确需经代理连接，则指向已有代理组，并保持出口稳定。
mode: rule
rules:
- DOMAIN,admin.shopify.com,办公代理
- DOMAIN,已核实的卖家后台主机名,办公代理
- DOMAIN-SUFFIX,公司内部服务域名,DIRECT
- GEOIP,CN,DIRECT
- MATCH,办公代理示例中的 GEOIP,CN,DIRECT 是可选的网络分流策略，不代表平台服务的所在地，也不保证一定符合你的网络需求。它依据目标 IP 数据库归属判断，不能代替对业务域名的确认。若不希望未匹配连接默认进入代理组，应按自己的配置目标调整末尾的 MATCH，并确保兜底策略明确、可验证。
节点与出站选择：稳定性比单次测速更重要
选择节点时，不要只看延迟数字。后台页面通常会并行加载登录接口、商品图片、订单数据和报表资源；某个节点对测速站响应快，不代表它对这些请求同样稳定。更实用的判断指标是连续访问是否成功、是否出现 TLS 握手失败或连接重置、页面资源是否完整，以及同一网络下结果能否重复。
- 优先保持出口一致：一个工作时段内尽量使用同一代理组和地区出口。节点故障时再切换，并记录切换前后的表现，避免同时改多个变量。
- 检查代理组选择：确认规则指向的组已存在，且组内选中的节点不是已失效项。自动测速或故障切换组的行为取决于配置，不应假设它一定选择最适合后台的线路。
- 区分 TCP 与 UDP：常规浏览器后台请求以 HTTPS 为主，通常需要可靠的 TCP 连接；若客户端启用了 TUN，其他应用流量也可能进入内核，但节点对 UDP 的支持仍取决于协议与服务端。
- 检查延迟以外的故障：连接超时、TLS 错误、DNS 解析异常和平台返回的登录验证页面是不同问题。不要把所有失败都归结为“节点速度慢”。
如果同一账号在不同网络和不同出口间频繁切换，可能增加平台要求重新验证的概率。不要通过轮换出口来规避平台的安全检查。出现验证码、登录提醒或安全验证时，应按平台页面提示完成流程；不确定时通过平台官方支持渠道核实。
动手排查：按“网络—规则—节点—浏览器”逐项验证
以下流程适用于 Windows、macOS 等桌面端常见 Clash 客户端。界面入口因 Clash Verge、Clash Verge Rev、Clash for Windows 或其他客户端版本而异，按功能名称查找，不要把某个版本的菜单路径当作所有客户端的固定路径。
- 建立基线：暂停其他 VPN 或代理程序，记录当前 Wi-Fi、有线或移动网络，并确认系统时间、日期和时区正确。先用浏览器访问一个平时可正常访问的普通网站，判断本地网络是否整体可用。
- 核对 Clash 状态：确认当前配置已加载、内核正在运行、规则模式已启用，代理组中选中了可用策略。不要同时改 TUN、DNS、端口与规则；一次只变更一个项目。
- 观察目标连接：打开 Clash 的连接或日志页面，再访问卖家后台。找到失败时间附近的域名、规则命中结果和出站策略。若记录中没有相关连接，先检查浏览器是否遵循系统代理，或该应用是否使用独立网络设置。
- 验证策略差异：对照连接记录，确认目标请求命中了预期的精确规则及策略组。若规则未命中，检查域名拼写、规则顺序和配置是否为当前生效版本；不要为了测试直接添加宽泛的整站后缀。
- 单独比较出站：在已有代理组中更换一个可信、稳定的节点后，重新打开新页面或新建连接进行测试。短暂切换直连只能用于比较本地网络路径；测试结束后恢复原模式与规则。
- 排除浏览器会话：若连接记录显示请求成功但页面仍异常，可在确认不会丢失未保存工作后，使用浏览器的无痕窗口或另一浏览器测试，并检查扩展、缓存和站点 Cookie。不要把登录 Cookie 导出或发送给他人。
- 保存结论并回滚：确认修复后记录改动内容、规则位置、策略名称和测试结果。若加入的规则没有改善问题，删除该规则并恢复原配置，避免留下无法解释的长期例外。
如果需要定位 DNS，可先看连接记录是否有域名解析错误，再检查当前内核的 DNS 设置与客户端覆盖项。不要同时更换多个公共 DNS、启用 fake-ip、开启 TUN 并改写规则；这些变化会让问题来源难以区分。使用自定义 DNS 前，应确认服务可信、当前网络可达，并理解 DNS 查询本身可能暴露访问元数据。
出差与日常运营：固定工作流，保护账号信息
出差时，酒店网络、机场 Wi-Fi、手机热点和公司网络的 DNS、防火墙及认证方式可能不同。先完成网络登录门户，再启动 Clash；如果酒店要求网页认证，不要为了“让所有流量都走代理”而把认证页也强制送入不可用的出站路径。工作结束后检查是否遗留系统代理、TUN 或其他 VPN 设置，避免下一次连接出现路由冲突。
团队协作时，应把订阅链接、控制接口口令、后台登录凭据和验证码视为敏感信息。截图提交给同事或技术支持前，遮盖账号邮箱、订单号、客户地址、Cookie、访问令牌及节点信息。分享排障结果时，提供脱敏后的错误类型、时间、客户端与内核版本、规则命中和策略名称即可。
- 为工作设备启用系统锁屏与磁盘加密，并使用平台支持的多因素验证。
- 不要在公共电脑保存后台密码，也不要让不可信的浏览器扩展读取卖家后台页面。
- 重要订单操作前确认当前登录账号、站点区域和页面域名；对可疑登录提示通过官方渠道核实。
- 遇到平台持续拒绝访问或要求安全验证时，优先检查账号通知和平台帮助信息，不要反复切换出口尝试绕过验证。
稳定访问的核心是可重复、可解释的网络配置，而不是不断叠加代理层。规则尽量精确，策略数量保持可管理，出问题时根据连接记录逐层定位。对于团队或多店铺环境，还应遵循组织的信息安全制度和平台账号管理要求。
常见问题
Shopify 后台打不开，是否应该把整个 shopify.com 设为代理？
不建议在未检查连接记录前这么做。主域名后缀规则可能影响多个子域名和不同用途的请求。先确认浏览器实际访问的后台主机名，以及失败请求是否进入 Clash，再为已核实的完整域名添加精确规则并验证效果。
Amazon Seller Central 必须固定使用某个国家的节点吗？
不能仅凭平台名称得出统一结论。卖家入口、账号区域、实际办公位置与平台安全要求都可能不同。使用符合平台规则、稳定且可信的网络，不要为了改变账号地区或规避安全检查而随意切换出口；出现验证要求时按平台指引处理。
规则模式下，为什么后台仍然直连？
可能是目标连接命中了 DIRECT 规则、没有命中预期域名规则而落到直连兜底、浏览器没有遵循系统代理，或连接走了未被当前方式接管的网络路径。查看连接记录中的匹配规则和出站结果，比只看模式按钮更可靠。
开启 TUN 能否解决所有后台连接问题？
不能。TUN 可以接管一部分不遵循系统代理的应用流量，但还会受操作系统权限、路由、DNS、排除项和内核配置影响，也不能修复账号权限或平台服务故障。先用系统代理完成基础验证，再根据确有需要的应用范围评估是否启用 TUN。