为什么 Fedora 上要单独写一套流程？

很多「在 Linux 上跑 Clash Meta」的帖子默认读者使用 Debian/Ubuntu：用 apt 装依赖、用 iptables-legacy 或 nft 的某种固定组合、再套一段 user systemd。换成 Fedora Workstation 后，包名与默认防火墙栈会变，SELinux 强制模式也会在你把二进制丢进非标准路径、或让服务监听额外端口时突然介入。更关键的是：TUN 并不是「打开 YAML 里一个开关」就结束，它依赖内核模块、设备节点、权能（capabilities）以及本机是否已有其他虚拟网卡或 VPN 抢占路由。

本文目标读者是：已经在别台机器或别的发行版上用过 Mihomo，希望在 Fedora 上得到可验收的安装结果——包含 dnf 依赖、systemd 自启、以及 TUN 启停顺序。若你更关心 TUN 与 DNS 的通用原理，可先读本站《Clash TUN 模式完全指南》，再回到本文处理发行版差异。

开始之前：确认内核、防火墙与工作栈

在 Fedora 上，绝大多数桌面用户走的是 NetworkManager + firewalld + nftables 的默认组合。Mihomo 开启 TUN 后会创建虚拟接口并下发策略路由；这与「只开系统 HTTP 代理」完全不同。建议你先记录三个基线：当前内核版本（uname -r）、是否安装第三方 VPN 客户端、是否改过默认防火墙区域。这些变量决定你后面排查「TUN 起来但断网」时是优先看路由冲突，还是看本机安全策略拦截。

另外，Fedora 默认启用 SELinux 强制模式。把可执行文件放在家目录并直接 systemd --user 跑，通常能工作；但若你把服务做成系统级 unit、二进制放在 /opt 或自定义路径，遇到「可执行却无法绑定端口 / 创建接口」时，应第一时间查 ausearch 与上下文标签，而不是反复改 YAML。

下文命令默认你在图形会话里具备 sudo。若你在 Silverblue/Kinoite 等不可变系统上操作，请把「安装依赖」替换为对应的 rpm-ostree 工作流；核心思路（权能、TUN、systemd）不变，但重启合并层的节奏会不同。

第一步：用 dnf 补齐运行与排错依赖

与 Ubuntu 的 apt install iproute2 iptables 不同，Fedora 上更常见的组合是 iproute、iptables-nft、procps-ng、bind-utils（dig） 等。Mihomo 本体往往以单个静态链接二进制分发，但系统侧工具仍要齐全，否则你在排错时会缺命令、或 TUN 依赖的 netlink 行为与预期不一致。

建议一次性安装下面这类「运行期 + 诊断期」依赖（包集合可按需微调）：

sudo dnf install -y iproute iptables-nft procps-ng bind-utils libcap policycoreutils-python-utils

其中 libcap 提供 setcap；policycoreutils-python-utils 提供 semanage 等 SELinux 管理工具，后面处理端口与文件上下文会用到。iptables-nft 与 nftables 在 Fedora 上是主流防火墙后端，和 Mihomo 在 Linux 上处理转发的路径密切相关——即使你最终主要用 TUN 而不是 redir，保持工具链完整也能减少「日志里提示创建规则失败却找不到对应命令」的尴尬。

第二步：放置 Mihomo（Clash Meta）与配置目录

你可以走两条路之一：使用带图形界面的 Linux 客户端（内核仍为 Mihomo），或直接运行上游发布的 mihomo 可执行文件。前者更适合日常桌面，依赖客户端自身处理更新与部分系统集成；后者适合希望完全掌控配置路径、用 systemd 托管的高级用户。

若选图形客户端，请优先从本站客户端下载页获取对应 Linux 包，再按发行版习惯解压到应用目录。若选纯二进制，推荐目录结构如下（示例）：

  • /usr/local/bin/mihomo：可执行文件（或符号链接）
  • /etc/mihomo/config.yaml：主配置（权限建议 root 只读或专用用户组）
  • /var/lib/mihomo/：运行期缓存、Geo 数据、下载的规则集

把二进制放在 /usr/local/bin 的好处是路径清晰、方便写系统级 service；代价是升级时要覆盖同一文件并重新应用权能。若你更在意「用户级隔离」，也可以放在 ~/.local/bin 并配合 user systemd，下文权能与 SELinux 段落仍适用，只是对象从系统路径换成用户家目录下的可执行文件。

第三步：SELinux 与 Linux 权能（CAP_NET_ADMIN）

TUN 模式需要创建虚拟网卡并操作路由表，进程通常需要 CAP_NET_ADMIN（以及视配置可能还有 CAP_NET_BIND_SERVICE）。在 Fedora 上，常见做法是二选一：以 root 运行（简单但不优雅），或使用 setcap 给二进制赋予最小权能集合。

示例（系统路径下的二进制）：

sudo setcap 'cap_net_bind_service,cap_net_admin+eip' /usr/local/bin/mihomo

执行后可用 getcap /usr/local/bin/mihomo 验证。若你更新二进制后权能消失，属于正常现象：需要重新 setcap。这也是为什么更推荐把「升级脚本」与「赋权」写在同一个维护步骤里，而不是手工记。

SELinux 方面，若日志出现 avc: denied 且与 mihomo、NetworkManager、unconfined_service 等相关，先用 sudo ausearch -m avc -ts recent 抓最近拒绝，再决定是调整布尔值、端口标签，还是为自定义路径添加 bin_t / 专用策略模块。对桌面用户而言，把长期运行的服务文件与二进制放在常规系统路径，通常比把可执行文件散落在家目录更利于 SELinux 的默认规则命中。若你暂时需要验证问题是否由 SELinux 引起，可在可接受风险且仅限本机实验窗口内用 getenforce 对照 Permissive 行为，但请不要把关闭 SELinux 当作长期方案。

第四步：编写 systemd 单元，实现稳定自启

与 Ubuntu 类似，Fedora 上同样推荐用 systemd 管理进程，而不是 nohup 或桌面「开机启动文件夹」。系统级 unit 适合监听低端口、创建 TUN、写入系统级路由；用户级 unit 适合只跑在用户会话里、配合图形客户端的场景。

下面是一个示意性的系统级 unit，请按你的路径与用户名修改：

[Unit]
Description=Mihomo (Clash Meta) Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

要点有三：（1） 为服务创建专用系统用户，避免以 root 长期运行；（2） -d 指向配置目录且其中包含 config.yaml；（3） LimitNOFILE 在规则集较大时能减少「打开文件过多」的隐性崩溃。创建用户与目录、设置权限、systemctl daemon-reload、systemctl enable --now mihomo 是标准流程；若启动失败，请立刻 journalctl -u mihomo -e，Mihomo 的报错通常比桌面弹窗更直接。

第五步：TUN 的正确启用顺序与验证

许多人在 Fedora 上「YAML 已写 tun.enable: true 但仍失败」，常见原因是顺序与前置条件没满足：二进制无 CAP_NET_ADMIN、配置里 auto-route 与现有路由冲突、或 NetworkManager 正在争抢默认路由。建议按下面顺序验收。

  1. 先不开 TUN，仅验证代理端口与规则
    用 mixed-port 或 HTTP/SOCKS 让浏览器走代理，确认订阅与 DNS 链路正常。若这一步失败，先不要开 TUN，否则你会同时面对「路由层」与「出口层」两类变量。
  2. 确认内核与设备节点
    绝大多数 Fedora 内核已内置 TUN；可用 lsmod | grep tun 或 sudo modprobe tun 验证。设备节点应为 /dev/net/tun，权限需允许你的服务用户打开。
  3. 开启 TUN 后检查接口与策略路由
    使用 ip addr 与 ip rule 观察 Mihomo 创建的接口与规则表项；若出现瞬间断网，记录变化前后差异，并对照是否与其他 VPN 的 table main 抢占有关。
  4. 用受控目标做连通性对照
    分别测试直连国内延迟、代理出口 IP、以及 DNS 解析路径；必要时用 dig 指定不同服务器对照，避免把「规则问题」误判成「TUN 坏了」。

若你需要同时理解 TUN 与 DNS、Fake-IP 的交互，可把本站使用文档里的 DNS 章节与本文并行阅读：发行版解决的是「权限与系统服务」，而 DNS 解决的是「解析路径与规则是否一致」。

第六步：NetworkManager、firewalld 与「断网感」

Fedora Workstation 上，NetworkManager 对 DNS 与路由的掌控力度很强。Mihomo 在 TUN 模式下若启用自动路由，可能与 NetworkManager 的拆分 DNS、按接口优先级管理冲突。遇到「全局断网几秒后恢复」或「仅部分应用走代理」时，建议先列出 NetworkManager 连接配置文件里是否强行指定了固定 DNS，再对照 Mihomo 的 dns 段。

firewalld 通常不会阻止本机进程创建的 TUN 流量，但在你把 Mihomo 暴露为局域网网关、或开启 allow-lan 监听时，需要显式放行对应端口区域。与 Ubuntu 上直接改 ufw 类似，Fedora 上要用 firewall-cmd --add-port=... 或永久写入区域规则；否则你会看到「手机能 ping 通笔记本 IP，但代理端口始终超时」的典型症状。

若你同时使用 WireGuard 或公司全局 VPN，尽量明确「谁负责默认路由」。两条栈都抢 0.0.0.0/0 时，表现往往是间歇性丢包或部分应用绕过 Mihomo——这不是 YAML 写错一行能解释的，需要从路由优先级入手拆问题。

排错速查：症状 → 优先检查项

现象 在 Fedora 上优先看什么
服务启动即退出，日志提权限 getcap 是否为空；是否忘记在升级二进制后重跑 setcap；unit 里 User 是否有权读配置目录
日志出现大量 SELinux denied ausearch / audit2why；二进制与配置路径的上下文；必要时调整端口标签或布尔值
TUN 开启后整机无网 ip route / ip rule；是否与其他 VPN 冲突；Mihomo 的 auto-route 与 DNS 劫持组合是否过激
局域网设备连不上本机代理端口 firewalld 区域、allow-lan 与监听地址；WiFi 访客网络或 AP 隔离

开源仓库与安装包获取方式

Mihomo（Clash Meta）上游以开源形式维护，许可证与提交历史可在各项目的 GitHub 页面查阅；若你参与排错或二次开发，Issue 与 Release 说明是最权威的信息源。需要强调的是：日常安装图形客户端或校验发布物完整性时，仍建议以本站下载页作为安装包入口，把「读源码、提 Issue」与「从哪获取可执行文件」分开，能降低中间链路与错误架构包带来的风险。

小结

在 Fedora Workstation 上跑 Clash Meta，本质是把三件事做对：用 dnf 把系统侧工具与诊断命令备齐，用权能与 SELinux 思维处理「为什么进程没权限动网卡」，用 systemd 把启动顺序与失败重试固化。TUN 不是孤立开关，放在「端口代理已验证通过」之后再启用，并用 ip / journalctl 做对照，能显著减少无效折腾。

与仅依赖帖子里的「复制粘贴一段 Ubuntu 命令」相比，按发行版习惯把防火墙、路由管理与安全模块纳入同一套检查清单，长期维护成本更低；而图形客户端路线则把部分集成细节交给官方构建，适合不想手写 unit 的用户。若你更在意各平台客户端的一体化体验与更新节奏，直接对齐到本站维护的发布集合，通常比在论坛链接之间跳转更省心。

→ 立即免费下载 Clash，开启流畅上网新体验

前往本站下载页获取客户端