1. 首次启动前:确认安装包、权限与原有代理
FlClash 是管理配置、代理节点与连接状态的客户端,实际转发由其集成的 mihomo 内核完成。安装成功只代表程序能够启动,不代表订阅已经加载,也不代表系统流量已经进入内核。第一次配置应把这三个环节分别检查,避免同时修改端口、DNS 与路由后失去判断依据。
开始前退出其他代理客户端和 VPN。仅关闭窗口可能只是缩小到托盘,应从托盘菜单退出,并检查系统代理是否仍指向旧程序。本文使用 7890 作为混合端口示例;它不是对所有 FlClash 版本默认值的声明。实际端口、选项名称与权限流程,以安装版本显示的内容为准。
按系统完成安装检查
- Windows:在「设置」→「系统」→「系统信息」查看系统类型。x64 与 ARM64 安装包应按设备架构选择。先用普通权限启动,只有启用 TUN、安装服务或创建虚拟网卡时,再按客户端提示授予权限。
- macOS:在苹果菜单→「关于本机」确认是 Apple 芯片还是 Intel 处理器。将应用放入「应用程序」后再运行。若系统拦截启动,先核实来源,再到「系统设置」→「隐私与安全性」查看具体提示,不要把关闭整个系统安全机制作为安装步骤。
- Android:安装 APK 时,仅向实际使用的浏览器或文件管理器授予「安装未知应用」权限,安装完成后可收回。不同厂商的设置入口不同,可在系统设置搜索该名称。首次启动 VPN 时另有系统授权弹窗,与安装权限不是同一项。
先保留已有可用配置的备份。订阅地址可能包含身份令牌,不要把完整链接、二维码或带令牌的日志截图发到公开讨论区。
2. 先导入订阅,再确认当前配置与节点
首次启动后,先进入客户端的配置管理入口,添加订阅链接或导入本地配置文件。粘贴订阅时检查首尾空格与换行,保留原有查询参数,不要把服务商的登录页地址当作订阅地址。订阅需要由用户自行准备,客户端安装包本身不等于可用代理服务。
- 在配置管理页新增远程订阅,填写可辨认的名称,粘贴完整链接并保存。
- 执行一次更新,等待下载和解析结束。出现错误时先处理错误,不要连续切换 TUN、DNS 或全局模式。
- 将导入的配置设为当前使用项。列表里存在订阅,不代表该订阅已经被加载。
- 打开代理或策略组页面,确认能看到节点以及分组。若分组是手动选择类型,选定一个实际节点;若使用自动选择组,检查组内有可用成员。
区分“导入成功”与“连接成功”
导入成功只说明获取的内容能被解析。节点过期、认证错误、服务端不可达,都可能在随后建立连接时才暴露。反过来,订阅更新失败也不一定表示节点失效:更新地址与代理节点地址是两条不同的网络路径。
如果返回内容是网页、登录提示或访问限制页面,即使 HTTP 状态是 200,也不是有效配置。查看更新错误中的格式与解析信息,再向订阅提供方确认客户端支持情况。不要把私人订阅交给陌生在线转换网站处理。
第一次拉取订阅时还没有可用代理,依赖代理才能访问的订阅地址可能形成启动依赖。应使用提供方给出的可达更新入口,或通过已有可信连接获取配置。反复打开一个尚未有节点可用的代理开关,不能解决这类依赖。
3. 系统代理与 TUN:首次验证只选一条接管路径
系统代理让遵循操作系统代理设置的应用把请求交给本地端口。TUN 则通过虚拟网卡与路由接管流量,适合不遵循系统代理的应用。两者可以在特定配置中同时存在,但初次排查时应只启用一条路径,减少路由、DNS 与代理设置相互影响的变量。
| 使用场景 | 首次选择 | 确认事项 |
|---|---|---|
| Windows、macOS 浏览器测试 | 系统代理 | 内核运行,代理地址和监听端口一致 |
| 不遵循系统代理的桌面应用 | TUN | 虚拟网卡权限、路由及 DNS 接管状态 |
| Android 常规使用 | 客户端 VPN 接管 | 系统 VPN 授权、应用分流与后台限制 |
| 仅测试命令行代理端口 | 显式指定代理 | 命令中的端口与客户端实际端口一致 |
Windows 与 macOS:先用浏览器建立基线
先启动内核,保持 TUN 关闭,再启用系统代理。Windows 可在「设置」→「网络和 Internet」→「代理」核对手动代理;macOS 可在「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」查看配置。菜单文字会随系统版本变化,但核对目标始终是代理主机与端口。
浏览器扩展、自带代理设置以及企业策略都可能覆盖系统设置。首次测试应暂时关闭代理扩展,使用普通浏览器窗口访问一个已知可直连页面和一个预期走代理的页面。若只有某个浏览器失败,先查该浏览器自己的设置,而不是立即重装客户端。
Android:VPN 图标不等于所有应用都已接管
启动连接时接受系统 VPN 请求,并检查是否有其他 VPN 正在运行。同一个 Android 用户通常只能保持一个活动 VPN 服务,其他 VPN、部分基于本地 VPN 的过滤工具可能与 FlClash 竞争。若启用了应用分流,还要确认测试浏览器在被接管的应用范围内。
Android 的系统 VPN 接管与桌面系统代理不是同一种机制。不要把桌面的 127.0.0.1:7890 直接填写成手机 Wi-Fi 代理,期待它指向电脑;手机上的 127.0.0.1 指的是手机自身。
4. 混合端口检查:7890、占用进程与监听地址
mixed-port 在同一个端口接收 HTTP 代理和 SOCKS 代理连接。应用端口必须与内核实际监听值一致。以下只是字段含义示例,不是可以直接覆盖订阅的完整配置,也不意味着需要手工修改这些值。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
mixed-port: 7890:手动设置代理的应用应使用相同端口。更换为7891后,也要同步更新浏览器、终端及其他手工填写端口的工具。allow-lan: false:首次仅供本机使用时保留局域网访问关闭。允许局域网连接还涉及监听地址、防火墙与认证,不应为了解决本机连接问题直接开放。mode: rule:按规则选择出站。它控制分流策略,不负责开启系统代理或创建 TUN 网卡。log-level: info:用于常规启动与连接检查。临时改为debug后应在排查完成后恢复,避免积累过多日志。
Windows:查找占用端口的进程
如果启动日志包含 address already in use,在 PowerShell 执行下面的命令。第一条列出监听端口和所属进程编号,第二条将编号转换为进程名称。无输出表示检查时未发现对应 TCP 监听,不代表内核一定已经正常启动。
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -LocalPort 7890 -State Listen |
ForEach-Object { Get-Process -Id $_.OwningProcess }
macOS:检查本地监听
lsof -nP -iTCP:7890 -sTCP:LISTEN
确认进程属于哪个程序后,再决定退出旧客户端还是修改端口,不要直接结束不明进程。端口冲突可能来自另一个代理程序,也可能来自重复启动的内核。若通过客户端设置调整端口,应重新启动内核,再核对运行值;订阅更新可能覆盖直接编辑的文件,持久修改应使用客户端支持的设置或覆写机制。
5. 规则模式、DNS 与连接测试的正确顺序
初始模式建议使用规则模式。规则通常按顺序匹配,首个命中的规则决定目标策略;策略组再决定使用哪个节点。全局模式仍依赖所选策略与节点可用,不能修复错误的节点密码、端口或传输参数。直连模式则不能用于判断代理节点是否正常。
按四层检查,不只看延迟数字
- 内核层:启动后没有配置解析失败、监听失败或权限错误。界面存在窗口不等于内核运行正常。
- 节点层:对当前策略组中的节点进行延迟测试。结果只代表测试地址与测试时刻的情况,不是实际下载带宽,也不能覆盖所有目标站点。
- 应用层:浏览器发起请求后,在客户端连接列表或日志中查找目标域名、命中规则与出站策略。看不到请求时优先检查接管路径。
- 目标层:请求进入内核但访问失败,再检查 DNS 结果、节点连接错误和目标服务的响应。页面的
403、429与连接超时属于不同问题。
在 Windows 中,也可以显式指定 HTTP 代理进行一次对照。以下命令适用于混合端口确实为 7890 的情况;macOS 可将 curl.exe 换为 curl。如果示例域名被规则分配为直连,成功只证明请求经过了本地代理入口,并不证明代理节点可用。
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/
DNS 方面,先保留订阅与客户端的既有方案。mihomo 的 Fake-IP 模式可能向应用返回映射地址,例如 198.18.0.0/16 范围中的地址,这不等于解析被污染。启用 TUN 后若发生解析失败,应核对 DNS 接管、上游解析器可达性及其他加密 DNS 设置,而不是同时更换多个公共 DNS。
浏览器自带的安全 DNS 可能改变解析路径,但不必然导致失败。只有在对照测试中确认它与当前接管方式冲突时,再临时关闭并复测。每次只改一个设置,并记录修改前的值。
6. 三个平台首次运行的高频卡点
Windows:系统代理已开,命令行仍然直连
部分命令行工具不会读取 Windows 系统代理,它们可能使用自己的代理参数或环境变量。先用上一节的显式代理命令验证,再查具体工具文档。不要因为终端没有被接管,就认定系统代理开关失效。若改用 TUN,应先确认浏览器基线正常,再授予所需权限并测试路由。
macOS:切换网络后代理失效,退出后无法访问
macOS 代理设置与网络服务有关,从 Wi-Fi 切换到以太网后,应核对当前服务的代理配置。退出客户端前先关闭系统代理,确认直连恢复。若程序异常退出,系统还保留指向本地端口的代理,而内核已停止,就会出现浏览器无法连接代理服务器的提示;此时应清理残留设置,而不是重复导入订阅。
Android:锁屏后断开,或只有部分应用失败
如果亮屏可用、锁屏一段时间后失效,先检查电池优化与后台运行限制。可在「设置」→「应用」→ FlClash 的电池相关页面,按需要允许后台运行;厂商系统可能还要求单独允许自启动。不要把省电限制与节点超时混为一谈,应对照断开时间和客户端日志。
若仅局域网设备、投屏或工作资料应用异常,检查应用分流、局域网绕过与工作资料隔离。局域网目标需要正确的本地路由;将所有流量强制送到远端节点,可能使打印机、NAS 或公司内网不可达。先记录目标地址与命中规则,再添加必要的直连规则。
7. 完成初始设置后的验收清单
首次配置应以可重复验证为结束条件,而不是以开关全部开启为结束条件。保持能说明原因的最小配置,之后再逐步增加开机启动、应用分流或自定义规则。
- 订阅已更新,当前配置已选中,代理组内有明确的可用节点。
- 内核运行正常,实际监听端口已记录,没有端口占用错误。
- 桌面先完成系统代理测试;确需 TUN 时,再单独验证权限、路由和 DNS。
- Android 已授予 VPN 权限,测试应用在接管范围内,后台运行状态符合需要。
- 直连目标与代理目标各测试一次,并能在连接记录中解释所用策略。
- 关闭连接后,普通网络能够恢复;重启客户端后,配置和节点选择仍符合预期。
- 订阅自动更新与开机启动在基础连接稳定后再启用,不同时叠加多个自动化开关。
需要逐项核对 mixed-port、mode 与规则语法时,可查阅配置字段参考。完整安装与操作流程见入门指南。后续出现问题时,保留发生时间、系统版本、客户端显示的版本信息、报错原文及最近一次设置变更,这些信息比反复重新安装更利于定位。