这篇教程解决什么问题？
很多用户在 macOS 或 Windows 上习惯了图形客户端一键「系统代理 + 可选 TUN」，换到 Ubuntu 后第一件事却是：命令行能跑、浏览器却各走各的，或者一重启就回到解放前。根本原因往往不在订阅，而在Linux 上代理是分层协作：用户态进程、systemd 生命周期、内核路由与虚拟网卡权限、桌面会话的环境变量，各自只负责自己的一截。
本文目标是把「Ubuntu Clash Meta 安装」补齐为可交付方案：安装 Mihomo（Clash Meta 内核发行版）、固定配置目录、用 systemd 实现 Linux systemd 自启、再按需启用 Clash TUN Linux 接管流量，最后把 apt、git、curl 与图形应用的行为尽量对齐。更偏理论的 TUN 原理与跨平台对照，可结合本站《Clash TUN 模式完全指南》阅读；内核能力与字段迁移背景可参考《Clash Meta（Mihomo）核心升级指南》。
开始前：权限、场景与目录约定
先确认你的使用场景是桌面还是无头服务器。桌面环境通常有登录会话，适合用户级 systemd（systemd --user）配合图形侧代理；服务器更常见的是系统级服务，由 root 或专用账户拉起，并显式管理监听地址与日志路径。
目录建议从一开始就统一，避免「今天 ~/Downloads 跑一下、明天 /opt 又一份」：
- 二进制：例如
/usr/local/bin/mihomo（系统范围）或~/.local/bin/mihomo（单用户）。 - 配置与工作目录：例如
/etc/mihomo或~/.config/mihomo，内含config.yaml、GeoIP数据与规则缓存。
无论你更习惯叫 Clash Meta 还是 Mihomo，在 Linux 上实际运行的通常是单一可执行文件 + YAML 配置。客户端安装包获取请优先使用本站下载页，以便版本与文档口径一致；若你需要核对开源许可证、Issue 或自行编译，可另行访问上游仓库，但不要把 Release 页当作面向新手的首选安装入口，以免版本与教程脱节。
第一步：安装二进制与最小可运行配置
将下载得到的可执行文件放到 PATH 中的固定位置，并赋予运行权限。随后在工作目录准备最小 config.yaml：至少包含端口、DNS、代理节点与规则骨架，确认 mihomo -d /path/to/config 能启动且日志无致命报错。订阅 URL、策略组命名、规则顺序属于「业务配置」，与「系统是否自启」是两件事；自启问题解决的是进程是否在正确时机被拉起、是否读到了你以为是的那份配置。
建议先用mixed-port或分离的 port / socks-port验证本机回环访问，再用浏览器或 curl -x 做冒烟测试。若你连这一步都不稳定，先不要打开 TUN，否则会把「路由层问题」与「节点/规则问题」搅在一起。
规则入门与匹配顺序陷阱见《零基础入门：如何为 Clash 编写自定义分流规则》，可把「最小可用」快速扩成可维护分流。
第二步：编写 systemd 单元，完成 Linux systemd 自启
systemd 的价值是把「手动启动」变成「随登录或随开机、可重启、可限权」的服务。常见两种写法：
- 用户服务：适合桌面用户，单元放在
~/.config/systemd/user/，用systemctl --user enable --now mihomo.service管理。 - 系统服务：适合服务器或希望全局统一拉起，单元放在
/etc/systemd/system/，用sudo systemctl enable --now mihomo.service。
一个可用的骨架如下（路径与用户名请替换为你的实际环境）：
[Unit]
Description=Mihomo (Clash Meta)
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.target上例面向系统级服务；若使用 systemd --user 用户服务，通常将 WantedBy 改为 default.target，并确保图形登录会话会启动用户级 systemd。改单元后记得 daemon-reload，并用 journalctl 看启动失败原因（权限、配置路径、端口占用是最常见的三类）。
第三步：为 Clash TUN Linux 准备权限与内核前提
TUN 的本质是让内核把一部分流量交给用户态程序处理。Mihomo 在 Linux 上启用 tun.enable 时，通常需要网络管理能力（常见为 CAP_NET_ADMIN），并依赖系统已加载 TUN 模块、具备 ip rule / ip route 等工具链。若你只设置了 YAML 里的 tun: 段，却在日志里看到创建接口或改路由失败，优先检查：
- 进程是否具备所需 capability，或是否以足够权限运行；
- 是否与其他 VPN、NetworkManager 插件或容器网络冲突；
stack选择（如 system 与 gvisor 的差异）是否与当前内核/场景匹配。
在 systemd 中，常见做法是为服务添加 AmbientCapabilities=CAP_NET_ADMIN 与 CapabilityBoundingSet=CAP_NET_ADMIN，并配合 NoNewPrivileges=false 等选项；具体组合取决于你的安全基线与是否还要监听低端口。不要默认假设「复制别人的单元就能用」，请以日志为准逐项放开最小权限。
YAML 侧一个常见的起点如下（需与你的路由、DNS、策略一致）：
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true启用后，用 ip link 观察是否出现虚拟接口，并用 traceroute、浏览器与纯命令行工具交叉验证。若只有浏览器正常而 apt 仍异常，多半还没走到 TUN，而是环境变量或代理模式仍停留在「仅 HTTP 端口」。
第四步：桌面环境的「系统代理」与环境变量对齐
Ubuntu 桌面用户常见误区是：TUN 已开，就认为所有工具都自动走代理。实际上，TUN 解决的是路由层接管，而某些应用仍会绕过或自带 DNS 逻辑；另一方面，仅依赖 HTTP 端口而不开 TUN时，大量工具根本不会去读 GNOME 的代理设置。
实践上可以采用「双轨」：
- 路由轨：TUN 开启且规则正确时，许多应用会随系统路由走内核路径；
- 变量轨：为 shell 与构建工具显式设置
http_proxy、https_proxy、ALL_PROXY，并维护no_proxy内网例外。
这与 macOS 上的终端排错是同一类问题，只是配置文件从 .zshrc 换成了 Linux 下的 .bashrc / .profile。若你在图形界面设置了代理，却仍遇到命令行直连，优先在终端打印 env | grep -i proxy，确认当前会话是否真的继承了变量。
服务器场景补充：监听地址、防火墙与远程管理
无头服务器上不建议把混合端口随意绑定到 0.0.0.0 除非配套认证与防火墙策略。更稳妥的是仅监听本机回环，由 SSH 端口转发或本地管理面板访问；若必须远程，务必限制来源 IP、使用独立鉴权，并理解这类暴露面属于运维责任。
同时检查 ufw / nftables 是否拦截了转发路径。TUN 会改动策略路由，云厂商的元数据地址、内网 API 也可能需要规则豁免，这与桌面「局域网直连」诉求类似，只是对象换成了机房网络。
排错顺序：建议按层剥洋葱
| 优先级 | 现象 | 优先核查 |
|---|---|---|
| 1 | 服务未随重启恢复 | systemd 单元是否 enable、路径是否一致、user 与 system 是否混用 |
| 2 | 进程启动即退出 | journalctl 日志、YAML 语法、端口占用、工作目录权限 |
| 3 | 仅 TUN 不通 | capabilities、路由冲突、DNS 劫持、stack 选择 |
| 4 | 浏览器通、终端不通 | 环境变量、NO_PROXY、工具自身代理设置 |
小结
Ubuntu 上安装 Clash Meta（Mihomo）并不是「下载完双击」这一条路径，而是二进制 + 配置目录 + systemd 生命周期 + 可选 TUN 权限 + 桌面/终端代理对齐的组合拳。把 Linux systemd 自启写对，意味着你获得的是可预测的重启行为；把 Clash TUN Linux 开对，意味着路由层能承接更多「不听话」的应用流量；再把环境变量补齐，命令行工具才能与图形世界同频。
若你希望减少版本错配、快速定位各平台客户端差异，可从本站客户端下载页统一获取安装包，并结合使用文档核对端口与模式说明。相比零散渠道，单一入口能显著降低「教程写着 A、本机却是 B」的隐性成本。
在稳定性与可维护性上，Mihomo 系内核提供了较完整的规则与模式组合；当你把 Ubuntu 这一层链路搭顺之后，Windows、macOS 与移动端经验可以复用到策略与排错，而不再需要为 Linux 单独发明一套玄学流程。若你尚未选定客户端或需要多平台并行部署，不妨从本站获取当前适配版本，再按本文顺序做一次完整验证。