sing-box 在 Linux 上以命令行和 JSON 配置为主，这既是它的门槛，也是它的优势：所有行为都写在一份可以版本管理的文件里，改了什么、什么时候改的，都能追溯。相比图形客户端，它更适合放在长期运行的机器上。
这篇梳理安装、配置结构与服务检查这条最小可用路径，并补上服务化运行之后的日常维护——装好只是开始，真正的问题往往出现在几周后的某次重启或升级。
如果你是从图形客户端转过来的，最需要调整的是心态：这里没有「点一下就好」的按钮，但换来的是每一次改动都可追溯、可回退、可以复制到另一台机器上。对需要长期稳定运行的场景来说，这份确定性通常比便利更值钱。
一、sing-box 是什么
官方项目把 sing-box 称为 universal proxy platform（通用代理平台），其配置采用 JSON 格式。理解“它是一个用 JSON 配置驱动的命令行程序”，是后续所有步骤的基础。
二、Linux 安装（以官方页面为准）
安装方式请以官方 包管理器安装页 为准。例如 Debian 系统的安装方式，官方页面上给出对应说明，按页面步骤操作即可。本文不复制粘贴具体命令细节，以免与官方页面更新脱节——请直接对照官方页面执行。
三、配置：先认识顶层结构
据官方 配置文档，一份 JSON 配置的顶层可能包含下列字段。先认识“有哪些块、各自大概管什么”，比一上来抄一份完整配置更重要。
| 顶层字段 | 大致用途（按官方文档概述） |
|---|---|
| log | 日志相关设置 |
| dns | DNS 相关设置 |
| ntp | 时间同步相关设置 |
| certificate | 证书相关设置 |
| inbounds | 入站相关设置 |
| outbounds | 出站相关设置 |
| route | 路由相关设置 |
| services | 服务相关设置 |
| experimental | 实验性设置 |
本文只列出顶层字段及其大致用途，不提供可直接使用的完整出站配置；具体字段含义请以官方配置文档为准。
四、检查配置与服务
官方提供 sing-box check 用于检查配置。写好或修改配置后，先用它做一次检查，是减少低级错误的实用一步。作为 systemd 服务运行时，实用的检查命令包括 enable / start / status，以及用 journalctl 查看日志。这些是运维时确认“服务是否按预期在跑”的常规手段。
五、上手检查清单
- 按官方包管理器页面完成安装，不照抄可能过时的第三方命令。
- 理解配置是 JSON，先认识顶层字段而非直接套用完整配置。
- 改完配置先跑
sing-box check。 - 作为服务运行时，用
enable/start/status与journalctl检查。 - 清楚本文不含性能或可访问性结论，也不含完整可用出站配置。
六、服务化之后的日常维护
作为系统服务长期运行时，最值得建立的三个习惯是：改配置前先备份、改完先 check 再重启、每次改动都记一句为什么改。第三条最容易被跳过，也最容易在两个月后让你后悔——面对一份自己写的配置却想不起某个字段是为了解决什么问题，是很常见的事。
另外建议把配置文件纳入版本管理（哪怕只是一个本地 git 仓库）。这样每次改动都有 diff，回退也只是一条命令的事。
七、改配置的固定流程
- 复制一份当前配置作为备份，文件名带上日期。
- 只改一处，并在提交信息或注释里写清目的。
- 运行配置检查命令，确认语法与结构没有问题。
- 重启服务，随即查看服务状态与日志，确认启动正常。
- 用一次真实请求验证行为符合预期，再继续下一处改动。
日志是这条流程里最有价值的部分：它能直接告诉你是配置没生效、还是生效了但结果不同。
八、长期运行时值得关注的几件事
日志体积。长期运行的服务会持续写日志，在小容量的机器上尤其值得留意。按官方说明配置合适的日志级别与轮转策略，避免几个月后被日志占满磁盘。
启动依赖。如果配置依赖网络就绪或某个目录挂载，机器重启后服务可能因为启动顺序而失败。重启一次验证服务能否自行恢复，比假设它会更可靠。
时间同步。不少协议对系统时间敏感，长期离线运行的机器时间容易漂移。确认系统的时间同步正常，可以省掉一类很难定位的连接问题。
这三项都属于「装好时没问题、几周后才发作」的类型，也正因如此值得在部署当天就顺手处理掉。
如果这台机器需要长期无人值守运行，还建议确认一次：断电重启之后，服务能否完全自动恢复到可用状态。这一条只有真的重启一次才能验证，而它恰恰是最不该等到出事时才发现的。
九、常见问题
服务起不来，从哪里看原因？
先看服务状态输出，再看系统日志中该服务的最近记录。多数启动失败在日志里有明确的行号或字段提示。
改完配置没生效？
确认是否重启了服务，以及改的是不是服务实际加载的那个配置文件路径。这两点占了绝大多数「改了没用」的情况。
要不要开机自启？
长期运行的机器建议开启，并验证重启后能自动恢复；只是临时使用的机器则不必，手动启动反而更容易掌握它当前是不是在运行。
配置文件该放在哪里？
按官方说明的默认路径存放最省事，服务默认会去那里读取。放在自定义位置时，务必确认服务实际加载的是你正在编辑的那一个文件。
要不要用容器来跑？
容器的好处是环境隔离、便于迁移；代价是网络配置更复杂，尤其涉及虚拟网卡与端口时。如果你还在熟悉阶段，直接装在系统上排查起来更直观。
改动要不要留记录？
要。哪怕只是在配置里加一行注释写清楚改动的日期和目的，几周后回头看时也能省下大量重新推理的时间，尤其是在多人共同维护的机器上。
怎么确认服务真的在按预期工作？
看三处：服务状态是否为运行中、日志里有没有反复重启的记录、以及一次真实请求是否走了预期的出口。三处一致才算确认。
升级之后配置报错怎么办？
先回退到上一个版本恢复服务，再对照发布说明确认字段变化。相关读法见Release 页不等于变更全貌。
