Clash 入门配置

01 导入订阅配置

启动客户端后，先进入「配置」或「订阅」页面，而不是直接打开系统代理。找到「新建」「添加」或「从 URL 导入」入口，将订阅地址完整粘贴到地址栏，名称可以填写便于辨认的用途说明。确认地址前后没有多余空格或换行，再点击下载或导入。订阅地址可能包含访问凭据，不要把完整地址贴进公开截图、问题讨论或在线转换页面。

下载结束后，配置列表一般会新增一张配置卡片，显示名称、更新时间或启用状态。此时还要点击「使用」「激活」或卡片上的选择按钮，让它成为当前配置；仅出现在列表中，不代表内核已经读取。正常情况下，客户端不会继续显示配置解析失败，切到「代理」页面后可以看到该配置定义的策略组与可选出口。

如果拿到的是本地文件，选择「从文件导入」，找到 config.yaml 或其他 YAML 文件并打开。扩展名只是识别线索，文件内容仍需符合客户端所用内核的配置格式。不要把网页另存为 YAML，也不要把一份只含节点链接的文本直接当成完整 Clash 配置。导入后同样需要选中启用，并检查策略组是否出现。

有些服务同时提供多种订阅格式，必须选择标注为 Clash、Clash Meta 或 mihomo 兼容的入口。浏览器能打开一个链接，只能说明服务器返回了内容，不能证明返回的是可解析配置。如果客户端提示语法或类型错误，先确认格式选项，再检查是否复制成了登录页面地址。不要为了消除报错，随意删除不认识的协议字段。

遇到「下载失败」时，先区分取回文件失败与加载文件失败。前者应检查地址是否完整、订阅权限是否有效、当前网络能否访问该地址；后者应查看客户端日志中的具体字段提示。某些客户端允许选择订阅更新时使用直连还是代理，首次尚未建立代理连接时，应避免让更新依赖一个当前不可用的代理出口。

订阅正常导入后，暂时不要把整份内容复制到手动编辑器里反复修改。远程更新可能覆盖直接编辑的部分，客户端自己的覆盖、合并或脚本功能也各有差异。首次使用先保持原配置，后续确有自定义规则需求，再了解持久化修改方式。现在确认当前配置已启用、策略组可见，即可进入下一步选择模式。

02 选择规则模式

返回首页或设置页，找到「模式」「运行模式」或 Mode，先选择 Rule，即规则模式。这个选项让已经进入内核的请求按照 rules 列表从上到下匹配，由首个命中的规则决定出口。它不会自动接管所有应用流量；接入系统代理或 TUN 是下一步的工作。先确定分流逻辑，再配置流量入口，后续更容易定位问题。

常见的另外两个选项是 Global 与 Direct。全局模式会把进入内核的请求交给全局策略处理，直连模式则使用直连路径。全局并不等于电脑上所有程序都已使用代理，直连也不等于关闭客户端。初次配置没有特殊测试需求时，保持规则模式即可，避免同时改变模式和网络接入方式，导致无法判断是哪一项设置影响了结果。

接着打开「代理」或「策略组」页面。这里可能有多个组，名称由配置作者决定，例如一个用于手动选择的主组，以及若干按用途划分的组。展开实际被规则引用的主选择组，选定一个已获授权、当前可用的出口。单击后通常会出现勾选、边框或当前选项文字变化；如果该组又选择了另一个组，就继续展开查看最终出口。

不要只凭名称判断策略含义。DIRECT 表示直连，REJECT 表示拒绝连接，它们不是普通远程节点。若主策略组当前选中 DIRECT，即使系统代理已经打开，相应请求也可能从本地网络直接出去。自动选择组则由配置中的检测地址和策略决定选项，不一定允许固定单个节点；需要手动固定时，应使用配置提供的选择组。

客户端上的「连接测试」「可用性测试」可以作为辅助信息，但测试成功只代表所配置的测试请求得到响应，不保证目标网站、账号登录或所有应用都能正常使用。测试失败也可能与测试地址本身有关。先选择一个有响应的出口，稍后再结合真实访问与连接记录验证，不要把检测数字当作唯一判断标准。

如果配置里没有预期的组，返回上一步检查当前启用的配置，而不是立即添加新的空白组。组名不统一是正常现象，关键是规则引用的名称能对应到真实策略。关于自定义规则、自动选择与协议类型的深入解释，可以查阅协议参考；常见界面与选择问题见常见问题。确认模式和出口后，下一步才开启应用流量入口。

03 启动内核与系统代理

先在首页确认内核处于运行状态。部分客户端启动后会自动运行内核，另一些需要点击启动或连接按钮。若页面显示配置错误、服务未启动或端口被占用，先处理该错误，再开启系统代理。系统代理只是把应用请求指向本机监听地址；内核没有监听时，提前开启会让浏览器等应用连接到一个没有服务的端口。

Windows 与 macOS 桌面客户端通常提供「系统代理」开关，打开后会写入相应系统设置。Ubuntu 图形客户端也可能提供同名开关，但桌面环境和安装方式会影响写入结果。操作后先保留客户端运行，再查看状态是否保持开启。如果已有另一个代理客户端或 VPN，建议先暂停其中一个入口，避免双方反复覆盖系统设置。

Ubuntu GNOME 可以打开系统「设置」，在「网络」中的「网络代理」查看当前值；不同版本的位置略有变化。若客户端没有自动设置，可切换为手动，填写本机地址 127.0.0.1，端口使用客户端实际显示的 HTTP 或混合端口。若配置使用 mixed-port: 7890，HTTP 与 HTTPS 代理栏通常都填这个地址和端口。

HTTPS 代理栏表示浏览器访问 HTTPS 网站时使用的代理入口，并不要求本机入口自身采用 HTTPS。不要因为栏位名称不同而随意更换端口。混合端口可以同时接收 HTTP 与 SOCKS5 请求；如果客户端使用独立端口，就分别按界面标注填写。7890 只是常见示例，实际配置已修改时必须同步更新系统或应用中的值。

桌面系统代理并不是所有程序都遵循的强制路由。浏览器通常会读取系统设置，但部分终端工具、游戏或独立应用可能使用自己的网络配置。先让一个浏览器正常工作，再处理其他应用。若只需要某个应用使用代理，可以在该应用中单独填写本机地址与对应端口；同机使用无需为了连接成功而打开 allow-lan，也不应随意放开控制接口。

Android 与 iOS 通常需要点击客户端中的连接按钮，并在系统提示中允许创建 VPN 连接。这是客户端接入流量所需的系统接口，不代表必须再安装另一款 VPN。若设备已有其他应用占用该接口，先明确要保留哪一个。移动端是否支持按应用分流，以及具体入口在哪里，取决于所用客户端与系统版本，不能直接套用桌面的系统代理步骤。

只有在目标应用不遵循系统代理，或明确需要更完整的流量接入时，再考虑 TUN。桌面端可能要求安装服务、授予管理员权限或创建虚拟网卡；不要一次同时开启多个未知开关。先记录当前可用设置，再单独测试 TUN。若开启后网络异常，先关闭 TUN 回到已验证路径，相关 DNS 与权限问题放到故障排查中继续处理。

04 验证请求与出口

连接按钮显示开启，并不能单独证明目标应用已经使用了预期出口。保持客户端运行，打开「连接」或 Connections 页面，再用浏览器新建标签页，访问一个允许访问且已知正常的网站。观察是否出现对应域名的新连接，以及浏览器是否获得正常响应。优先使用新请求，已有的长连接可能还保留之前的路径。

点开该连接的详情，查看目标域名、命中规则、使用的策略组或代理链。不同客户端展示字段略有差别，但应能判断它是直连、经某个组转发，还是被规则拒绝。规则模式下，一部分网站直连是预期结果。若要确认远程出口，应该选择按当前规则确实会进入代理组的请求，而不是要求每条连接都显示同一个节点。

必要时可以通过可信的出口 IP 查询服务辅助判断，但应结合连接记录一起看。查询网站本身也会受到分流规则影响，返回本地出口不一定说明代理没有工作。浏览器缓存、已有连接以及站点按账号或定位权限显示的地区，也不能替代网络路径判断。验证重点是「这个应用的这个请求，是否按预期进入内核并选择出口」。

熟悉终端的桌面用户，可以用下面的命令显式指定 HTTP 代理，访问标准示例站点。请将端口替换为客户端实际监听的混合端口或 HTTP 端口。该测试用于区分「内核入口可用」与「应用是否读取系统设置」，不会证明所有终端工具已经自动使用代理。

curl --proxy http://127.0.0.1:7890 --head https://example.com

如果显式代理命令成功，而普通浏览器没有对应连接记录，优先检查浏览器是否使用系统代理、是否被扩展覆盖，以及系统设置中的端口是否正确。如果连接记录已经出现但请求失败，继续查看命中策略与相关日志；此时反复打开系统代理开关通常没有帮助。不要通过关闭证书验证来绕过 HTTPS 警告，应先检查系统时间、目标站点与出口状况。

如果所有请求都失败，按固定顺序回查：当前配置是否真的启用，内核是否运行，本机端口是否监听，应用请求是否进入内核，最后才是所选出口是否可用。每次只更改一项并重新发起请求，避免把配置、DNS、TUN 与模式一起修改。遇到端口冲突，可以参考端口占用与 mixed-port 调整，不要在不清楚用途时结束系统进程。

验证通过后，保留已确认可用的模式和策略组选择，再根据需求设置订阅更新与开机启动。下一次订阅更新后，组内项目可能变化，出现异常时先查看当前选择是否仍然有效。Ubuntu 服务化运行与协议选型属于后续进阶内容，参阅协议与内核参考即可，不必为了首次连接提前配置整套服务。

完成标准：配置加载成功、内核运行、应用新请求出现在连接记录中，并且命中规则与出口符合预期。退出客户端前，先关闭系统代理或恢复之前的网络代理设置；若开启过 TUN，也应确认客户端已正常释放相关网络入口。