Clash 首次安装后的初始设置：系统代理、混合端口与开机启动常见坑

首次运行：先确认配置、内核与连接出口

Clash 客户端窗口能打开，不等于代理链路已经接通。完整链路至少包括：客户端加载配置、内核成功监听本地端口、应用把连接交给内核、规则选中有效出口。首次设置时应按这个顺序逐段检查，不要同时打开系统代理、TUN 和多套网络工具，再靠刷新网页猜原因。

本文以桌面 Clash 类客户端及使用 Clash Meta（mihomo）内核的客户端为主要对象，并补充 Android 与 iOS 的差异。不同客户端的菜单名称会变化；系统代理、规则模式和虚拟网卡是不同层级的功能，不能把桌面端的开关位置直接照搬到手机端。

1. 加载配置：在客户端的订阅或配置页面导入服务方提供的兼容配置，更新成功后将其设为当前配置。列表里出现文件不代表该文件已经启用。
2. 查看内核日志：确认没有 YAML 解析错误、代理组引用不存在或端口绑定失败。日志里持续报错时，先修配置，不急着改系统网络。
3. 选择规则模式：首次使用优先保留配置原有的规则模式。全局模式只是把连接交给全局策略，并不能修复错误的节点参数。
4. 检查策略组：手动选择组需要选中可用节点；如果选中的是 DIRECT，相应流量仍会直连。延迟测试成功只说明该测试目标可达，不保证所有网站均能访问。

系统代理：决定哪些应用会使用本地端口

桌面客户端中的“系统代理”通常是修改操作系统的代理设置，把遵循该设置的应用指向本机地址，例如 127.0.0.1:7890。它不等于接管全部网络：部分游戏、命令行工具、独立设置代理的浏览器，以及某些 UDP 流量，不会自动跟随这个开关。

Windows：检查代理地址，不要只看托盘图标

在 Windows 11 中打开「设置」→「网络和 Internet」→「代理」，查看「手动设置代理」中的地址与端口是否和客户端一致。客户端可能采用不同的系统代理配置方式，应以其说明和当前实际设置为准。普通桌面应用使用的系统代理与 WinHTTP 配置也不是一回事，不要为了浏览器问题随意修改 WinHTTP。

macOS：按当前使用的网络服务检查

在 macOS 中进入「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」。重点检查网页代理、安全网页代理或 SOCKS 代理是否仍指向旧端口。Wi-Fi 与有线网络的设置可能不同；切换网络后出现异常，要检查当前网络服务，而不是只检查原来的 Wi-Fi。

Linux：桌面环境与终端分别确认

Linux 的桌面代理设置受桌面环境和应用实现影响。终端程序通常需要显式代理参数或环境变量，不能因为浏览器已经走代理，就认定终端也已接入。下面两条命令分别通过同一混合端口测试 HTTP 代理和 SOCKS5 代理：

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

socks5h 表示将目标域名交给代理端解析。收到目标站点的 HTTP 响应，说明本次请求至少完成了连接与响应过程；超时、代理认证错误和 TLS 错误则需要分别判断。此测试不代表所有应用已接管，也不代表本地 DNS 设置已经正确。

mixed-port：7890 只是常见端口，不是固定要求

mixed-port 将 HTTP 代理与 SOCKS 代理放到同一个监听端口。它是本地入口，不是远端节点端口，也不是用于控制内核的 API 端口。常见配置使用 7890，但不同客户端、不同配置可能选择其他值，应以当前生效配置和运行日志为准。

怎样确认端口被谁占用

如果日志包含 address already in use 或绑定失败，先检查监听进程。另一款代理客户端、旧内核后台进程以及开发服务都可能占用同一端口。以下命令中的 7890 应替换为报错端口：

# Windows：在命令提示符中执行，结果末列为 PID
netstat -ano | findstr :7890

# macOS：查看 TCP 监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看 TCP 监听及进程信息
ss -ltnp 'sport = :7890'

Windows 输出可能包含远端端口相同的连接，应同时看本地地址列和 LISTENING 状态。Linux 若看不到进程名称，可能需要额外权限。确认进程身份后，优先正常退出冲突程序，不要看到 PID 就直接强制结束。

换成 17890 后，应用也要同步修改

如果确实需要避开冲突，可以把混合端口改为 17890。下面仅展示需要核对的字段，不是一份包含节点与规则的完整配置：

mixed-port: 17890
allow-lan: false
mode: rule

修改后重新加载配置，确认新端口已监听，再关闭并重新开启客户端的系统代理开关。手动填写过代理的浏览器、终端和下载工具也需要同步修改。部分图形客户端会用自己的端口设置覆盖订阅字段，应在客户端设置或其支持的覆写配置中修改，否则订阅更新后可能又变回旧值。

TUN 与权限提示：先跑通普通代理，再扩大接管范围

TUN 模式通过虚拟网络接口和路由接管流量，适合不遵循系统代理的应用，但它不是“更高级所以必须开启”的选项。桌面端第一次配置时，可以先用显式代理请求确认节点和本地端口工作，再按需要启用 TUN，避免把节点故障与路由问题混在一起。

• Windows：创建虚拟网卡、添加路由等操作通常需要提升权限，客户端可能通过服务模式完成。出现服务安装失败时先检查日志，不要长期把所有程序都以管理员身份运行。
• macOS：系统代理修改、辅助服务或网络扩展可能触发不同授权。仅对来源明确、与当前操作相符的请求授权；无法启动时检查客户端提供的辅助服务状态。
• Linux：创建 TUN 设备和调整路由涉及网络管理权限，具体可通过服务或能力配置实现。应遵循所用客户端的说明，不能用一次桌面代理成功推断 TUN 权限也已齐全。
• Android：常见客户端通过系统 VPN 接口接管流量，需要确认 VPN 连接授权。它与桌面上的系统 HTTP 代理开关不同；另一款 VPN 应用可能占用同一系统通道。
• iOS：使用支持相应配置的客户端，并确认其 VPN 配置授权。不能把桌面 Clash 安装包用于 iOS，配置格式和功能支持也要按具体客户端核对。

TUN 开启后若局域网设备、公司内网或其他 VPN 异常，先关闭 TUN 对比恢复情况，再检查路由排除项与 DNS 设置。不要直接复制一套陌生的 DNS 配置：内网域名、路由器域名和普通公网域名的解析路径未必相同。需要进一步理解流量接管时，可查看技术参考。

开机启动：客户端自启、内核运行和代理恢复是三件事

“开机启动”通常指用户登录后启动客户端，不一定表示登录前就有代理服务，也不保证启动后会自动加载正确配置、恢复系统代理或开启 TUN。首次验证应做一次完整的退出、重新登录或重启测试，而不是只观察设置开关是否变亮。

1. 启用客户端自启：在客户端提供的启动设置中开启相关选项，并确认程序已经移动到准备长期使用的位置。不要从临时解压目录、磁盘映像或即将删除的安装目录运行。
2. 检查系统启动项：Windows 11 可到「设置」→「应用」→「启动」核对；macOS 可到「系统设置」→「通用」→「登录项与扩展」核对。Linux 则检查当前桌面环境的自启动应用或对应服务。
3. 确认启动后的实际状态：查看当前配置是否仍被选中、策略组是否恢复预期选择、监听端口是否正确，以及系统代理或 TUN 是否按客户端设置启用。
4. 等网络就绪再判断订阅更新：登录后 Wi-Fi、门户认证或公司网络可能尚未就绪。此时自动更新失败不等于本地已有配置不可用，应先检查网络，再手动重试更新。

移动端还要检查后台与电池策略

Android 的后台限制可能使代理服务在锁屏后被终止。若出现“刚打开正常，过一会儿断开”，应查看客户端是否仍显示运行、系统 VPN 状态是否保留，以及系统电池管理是否限制后台。仅对确有需要的应用调整策略，不必关闭整机的所有省电功能。iOS 的自动连接行为则取决于客户端和系统支持，不应承诺与桌面自启完全一致。

首次安装排查顺序：从本地监听到应用接入

排查要按层次缩小范围，每次只改一个变量。下面这张工单表适合在“节点看似正常，但应用无法访问”时逐项对照：

对照客户端连接记录还能进一步定位：完全看不到目标请求，通常要检查接入路径；请求出现但命中 DIRECT，应查看规则与策略组；请求进入代理出口却超时，再检查节点可达性和目标站点。日志级别可以临时提高用于定位，问题解决后恢复常用级别，避免持续产生大量日志。