配置与可执行文件在服务模板里各有位置
mihomo Linux 服务文档将二进制放到 /usr/local/bin，把 config.yaml 放到 /etc/mihomo。systemd 单元则是 /etc/systemd/system/mihomo.service，它们不是同一个文件。
| 文档中的对象 | 对应位置或动作 |
|---|---|
| 内核程序 | /usr/local/bin/mihomo |
| 配置文件 | /etc/mihomo 中的config.yaml |
| 服务单元 | /etc/systemd/system/mihomo.service |
| 启动目标 | mihomo读取指定目录 |
| 日志 | journalctl按mihomo服务查看 |
这些位置属于该文档方案，不能据此宣称每个客户端也把配置存到这里。图形工具可能管理自己的工作目录，查当前文件时先确认运行的是裸内核还是图形客户端。
订阅来源与已准备配置不能直接互换
你手里若是服务给的订阅地址，仍需核对它返回的配置是否供 mihomo 使用。这份 Linux 运行说明没有写转换操作，具体转换办法没查到公开说明，不编第三方处理流程。
- 确定当前文件来自哪里，并保留来源说明。
- 把实际配置与文档的配置文件位置对应起来。
- 记录运行对象是内核服务，不用图形订阅菜单替代。
文件名叫 config.yaml，只能说明你在对应这个文档位置，不是格式有效性的独立证明。服务能否读入的结果按实际提示记录，不能从改名动作推出配置已兼容。
文件位置、文件内容与服务状态是不同核对项，名称一致不替内容作证。
服务管理按已有命令逐项对应
官方步骤列有重新读取服务单元、启用服务、启动、重新加载与查看状态。它们分别处理服务管理动作，执行过其中一个，不代表其他动作也已经完成。
- 对照文档的程序、配置和服务单元位置。
- 有对应单元后，再按公开列出的服务管理命令核对动作。
- 读取状态与日志，保存实际返回，不先替错误判断原因。
文档列出的命令包括 systemctl daemon-reload、systemctl enable mihomo、systemctl start mihomo、systemctl reload mihomo 和 systemctl status mihomo。命令各有对象，不把启用与立即运行合并解释。
日志读取使用服务名对应记录
公开日志写法为 journalctl -u mihomo -o cat -e，另有 journalctl -u mihomo -o cat -f。检查时保留完整命令与对应服务，不替它增加未提供的日志文件路径。
Linux 内核二进制提供不同架构与编译标签，当前选中的文件也要与设备条件对应。无额外标识版与 compatible 的现行差别没有明确统一说明，不从旧解释推定当前条件。
软件包安装与文档模板不要合并为默认保证
mihomo 的 deb、rpm 安装后是否自带 systemd 服务，没查到公开说明。这里引用的是文档给出的单独方案，不能把它写成所有安装方式完成后都已存在的服务。
文档先写移动又列 cp 命令，页面没有创建配置目录的完整步骤。原有文字的范围保留下来，不替它补出一段假称官方完整安装流程。
若配置来源需要更换可另行查看
其他机场的收录入口在下面，便于你另问实际订阅与配置条件。
常见问题
下单前常见的疑问
服务模板里的配置目录是哪一个？
公开方案把 config.yaml 放在 /etc/mihomo，并让内核从指定目录读取。它属于这份服务模板，不能据此认定图形客户端的配置也在同一个目录。
deb安装之后一定已有mihomo服务吗？
软件包是否自带 systemd 单元没查到公开说明，不能把手动模板方案写成安装后的默认状态。先区分安装方式，再核对实际服务与对应文档。
读取日志时可以直接找一个猜测的文件名吗？
用文档已列出的 journalctl 服务读取方式，保留 mihomo 服务名。这里没有给出统一日志文件路径，不用猜测路径替代实际返回信息。
选好档位，再去结算页核对一次
流量够用比单价更重要；结算页显示的价格与这里不同时，以结算页为准。