Clash 订阅链接怎么导入：完整 YAML、节点列表与分享链接的区别

一、先判断输入内容，再选择导入入口

“复制链接后导入”只适用于客户端能够识别的输入。订阅 URL 是获取内容的地址，YAML 是一种配置文本格式，单节点分享链接则是某个节点的参数载体。这三者不在同一层：同一个 HTTPS 地址可能返回完整配置、节点列表，也可能返回登录页面。地址能在浏览器打开，并不代表它能作为 Clash 配置加载。

客户端负责界面、订阅下载与配置管理；Clash 或 Clash Meta（mihomo）等内核负责解析有效配置、建立代理连接、匹配规则及处理 DNS。某些客户端带有格式转换能力，但不能据此认定所有 Clash 客户端都能直接导入任意分享链接。开始前应在“关于”或内核信息页面记录客户端版本与内核版本，二者不能互相替代。

手中的内容	典型特征	应寻找的入口
远程订阅 URL	以 `https://` 开头，可能带鉴权参数	远程配置、URL 导入或新建订阅
本地 YAML 文件	通常为 `.yaml` 或 `.yml`，内容是结构化文本	本地配置、从文件导入
节点提供器内容	常见顶层为 `proxies:`，没有策略组和规则	由主配置中的 `proxy-providers` 引用
单节点分享链接	以 `ss://`、`vmess://`、`trojan://` 等开头	客户端明确提供的节点导入或转换入口

二、订阅 URL 导入：下载、选中与生效是三个步骤

先取适配当前内核的订阅地址

在订阅提供方的管理页面，选择与客户端内核匹配的 Clash 或 mihomo 输出。不要直接复制账户中心页面的地址，也不要把“一键导入”按钮的客户端唤起协议当成 HTTPS 订阅地址。若提供方区分旧版 Clash 与 mihomo，选择依据应是实际运行的内核，而不是桌面快捷方式的名字。

检查复制结果：链接前后不应带引号、空格或聊天软件追加的标点。保留原有鉴权参数；修改参数可能导致服务端拒绝访问。
创建远程配置：进入客户端的“配置”或“订阅”页，找到 URL 输入框或远程配置的新建入口，粘贴地址并下载。不同客户端的按钮名称与排列会变化。
查看导入结果：确认配置列表新增了记录，并检查更新时间、节点数量及下载错误。仅出现配置名称，不能证明内容已经正确解析。
选中并应用：把新记录设为当前配置。部分客户端导入后仍使用旧配置，需要再次点击配置卡片或执行应用操作。
核对运行状态：查看内核是否运行、策略组是否出现、是否存在未知协议或目标不存在的错误，再做连接验证。

以带有 Profiles 页面和 URL 输入框的 Clash for Windows 旧版界面为例，路径通常是 Profiles → URL 输入框 → Download，随后还要选择对应配置卡片。这只是旧界面入口示例，不代表其仍在维护，也不适用于所有客户端；新版客户端请按“远程配置”的功能含义寻找对应入口。

首次导入不必同时开启 TUN、修改 DNS 和更换全部规则。先确认配置能加载，再确认代理接管方式，才能把故障范围控制在单一环节。若下载订阅本身需要已有代理，应使用能够工作的旧配置，或按提供方支持的网络路径获取；新配置尚未下载时，不能依赖它解决自己的下载问题。

三、本地 YAML：检查内容完整性与引用关系

本地导入适合离线配置、备份恢复和手动编辑。文件扩展名只是线索：把一个网页改名为 config.yaml，不会让它成为配置。用纯文本编辑器打开文件，检查是否出现 <html>、登录提示或接口错误信息。YAML 的缩进使用空格，不要混入 Tab；编辑器应显示实际扩展名，避免保存成 config.yaml.txt。

完整配置不是“含有 proxies 就够了”

一个能够承担预期代理分流工作的配置，通常需要节点或节点提供器、策略组、规则，以及合适的监听设置。具体字段是否必填取决于内核默认值与客户端生成机制，但规则目标必须能解析：规则指向 Proxy，就应存在同名策略组或节点，不能仅靠界面显示名称来推断。

# 配置示意：只验证结构，不包含远程代理节点
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

本地文件导入后，不应默认它保留原订阅的自动更新关系。客户端可能复制文件到自己的配置目录，也可能直接引用原路径；编辑桌面上的源文件未必影响正在运行的副本。应从当前配置记录的编辑或查看功能确认实际内容，再修改并重新加载。操作前保存一份带日期的备份，例如 config-backup-2026-06-16.yaml。

如果文件使用 proxy-providers 或 rule-providers，本地 YAML 只是入口，启动时仍可能需要下载外部资源。复制主文件不等于复制了全部依赖。检查提供器路径、远程地址与缓存是否可用，特别是从另一台设备迁移配置时，不要照搬原设备的绝对路径。

四、只有节点列表或分享链接时怎么处理

节点列表需要被主配置组织起来

顶层只有 proxies: 的 YAML 常用于节点提供器。它描述可用节点，却未必定义应用应使用的本地端口、策略组和分流规则。把它作为主配置导入，有些客户端会补齐必要结构，有些只显示节点或直接报错；不能把某个客户端的补全行为当作通用格式约定。

在支持提供器的内核中，通常由主配置在 proxy-providers 中定义一个命名资源，再由策略组通过 use 引用它。提供器名称必须一致，远程资源也必须是内核支持的节点格式。不能仅将普通订阅 URL 填入该字段，就假定内核会解码任意 Base64 节点订阅。相关字段可对照配置大全的节点说明核对。

分享链接要同时考虑解析能力与协议支持

单节点 URI：ss:// 等链接携带一个节点的参数，不包含完整分流规则。只有客户端明确支持该类型的导入，才能直接使用。
多行 URI 或 Base64 文本：它们可能是通用节点订阅，但不是完整 Clash YAML。需要提供方输出兼容格式，或由可信工具转换。
协议与传输参数：转换后仍须核对协议、端口、TLS、SNI、传输路径等。旧 Clash 内核不等同于 mihomo，不能假设两者支持同一组协议与字段。

出现“未知协议”时，先查当前内核的支持范围；出现连接握手错误时，再对照原始参数。不要通过删除无法识别的字段强行消除报错：该字段可能正是服务端要求的传输或认证参数。需要更换客户端时，先在选型指南核对平台与内核关系，再迁移配置。

五、订阅更新失败：按响应、解析、连接分层排查

“更新失败”至少包含三类问题：请求没有拿到内容、拿到的内容不能解析、解析成功但节点无法连接。节点延迟测试失败不等于订阅更新失败；同样，HTTP 请求成功也不等于配置正确。应先看配置更新时间和下载日志，再看内核报错，最后测试业务连接。

具体信号	优先检查	下一步操作
HTTP 401 或 403	令牌失效、账户权限、访问限制	重新获取订阅地址，检查账户状态；403 也可能来自访问防护
HTTP 404	地址路径变化、复制不完整	对照提供方当前生成的地址，不手动猜测路径
HTTP 429	刷新过于频繁	停止连续重试，按响应提示或提供方规则等待
HTTP 200，但解析报错	返回网页、错误 JSON 或不兼容节点格式	在本机检查响应开头与报错行，确认适配格式
DNS 失败或连接超时	订阅域名解析与下载所走链路	检查本地联网、现有代理和订阅更新的代理设置
TLS 证书错误	系统时间、证书链、认证门户或网络拦截	校准时间并确认网络状态，不把关闭证书验证作为常规修复

浏览器下载正常而客户端失败，还要检查跳转、登录 Cookie、请求头及提供方的客户端识别策略。浏览器可能因为已登录而拿到文件，客户端则得到登录页；反过来，服务端也可能按 User-Agent 返回不同内容。解决办法是取得面向目标客户端的订阅入口，而不是把浏览器登录会话复制到不相关的软件中。

遇到 yaml: line 12 一类提示，检查第 12 行及其上一行的缩进、引号和冒号。报错行常是解析器发现异常的位置，不一定是最初写错的位置。若远程内容本身有问题，优先联系提供方或切换其支持的输出格式；本地临时修好后，下一次更新仍可能取回原错误内容。

六、更新覆盖本地修改：把订阅与覆写分开

远程订阅通常是可重新下载的源文件。直接在它里面加入规则、修改端口或重命名策略组，下次更新就可能被覆盖。这是内容更新方式造成的结果，不一定是保存失败。客户端的运行配置还可能由“订阅内容＋全局设置＋覆写”合并生成，因此编辑某一层后，要确认最终生效值。

保留订阅原件：把远程地址和自动更新留在远程配置记录中，不把唯一副本改成难以恢复的手工版本。
单独存放修改：如果客户端提供覆写、合并或脚本功能，用它保存自定义规则与设置；具体执行顺序以该客户端实现为准。
检查数组行为：rules 和 proxy-groups 可能被替换、前插或后追加，不能假设所有合并机制都相同。
复查规则顺序：规则通常按顺序匹配，自定义规则放在 MATCH 之后往往不会生效；规则引用的策略组也要在更新后继续存在。
做一次手动更新：比较更新前后的有效配置，确认订阅刷新成功，同时自定义设置仍在，再开启定期更新。

七、导入后的最小验证清单

导入成功的判断应覆盖配置、内核和实际请求三个层次。先不要用“所有节点都测一遍”代替基础检查：延迟探测使用的目标可能不可达，而浏览器仍能通过该节点访问其他站点；也可能探测成功，应用却没有走代理。

配置层：当前选中的是新配置，更新时间符合本次操作，目标策略组存在，组内选择了预期节点而非 DIRECT。
内核层：没有解析失败、端口占用或未知协议错误；查看实际监听端口，不能只照抄教程中的 7890。
接管层：桌面系统代理主要影响遵循系统代理设置的应用；TUN 涉及虚拟网卡、路由与权限，移动端则通常需要 VPN 授权。它们都不能修复错误的订阅格式。
请求层：访问一个已知可用的网站，在连接或日志页观察是否进入内核、命中了哪条规则、最终使用哪个策略。

用显式代理请求隔离系统代理问题

若桌面设备已安装 curl，且内核确实在本机 7890 端口提供 HTTP 或混合代理，可执行下面的诊断命令。Windows 可使用 curl.exe，避免部分 PowerShell 环境中同名别名带来的参数差异。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

这里的 10 秒是连接超时上限，20 秒是整个请求的时间上限，不是实测延迟。收到 HTTP 响应说明这次显式代理请求完成了响应过程，但不证明用了远程节点，因为规则仍可能选择直连。若提示无法连接 127.0.0.1:7890，先查监听端口和内核运行状态；若显式请求成功、普通浏览器失败，再查浏览器代理设置或其他接管冲突。

最后保存脱敏后的错误信息、客户端与内核版本、输入类型和复现步骤。继续调整前可对照快速上手的连接验证，确保每次只改变一个变量。这样可以明确问题发生在订阅获取、配置解析还是代理链路，而不是在反复导入和重装中丢失线索。