Linux

结论与验证状态 本次排查定位到：sing-box 的主要 CPU 开销来自连接所属进程查询，尤其是构建进程路径信息的 buildProcessPaths。故障出现前刚新增了 process_name 匹配规则，该变更与热点高度吻合，是首要触发因素。 已验证的是性能热点；尚未收到移除规则后的对照复测结果。 因此不能把“已移除并恢复正常”写成既成事实，也不能直接归因于某个已确认的版本 Bug。 本文已去除个人主机名、账户名，将原规则中的程序名替换为 example-cli。 环境与现象 设备：N1，Linux ARM64。 sing-box：1.14.4。 Go 构建环境：go1.26.10 linux/arm64，CGO enabled。 Revision：c005f35300ce76427dc285481ec5695f5b179cd2。 现象：外部流量低、日志平静，但 CPU 持续很高。 perf 未安装；最终采用 sing-box 内置 pprof，在 Mac 上分析采样。 最初 top 输出： PID COMMAND VIRT RES SHR %CPU %MEM TIME+ 20776 sing-box 1484040 130060 41288 355.4 7.1 139:35.45 在通常的 top CPU 计数模式下，355.4% 表示约占用 3.55 个核心。RES 约 127 MiB；VIRT 约 1.42 GiB 并不等于实际物理内存占用。TIME+ 是累计 CPU 时间。 初始猜测包括忙循环、GC 压力和内部流量回环；这些仅是排查方向，不能当作诊断结果。 ...

连接 WireGuard 后，有时只希望内网域名通过隧道中的 DNS 查询，其他域名仍使用公共 DNS。对于已经使用 systemd-resolved 的 Linux 系统，可以直接配置 DNS 路由域，再通过 wg-quick 的 PostUp 自动应用，无须额外安装 DNS 转发服务。 ...

在一台用作旁路由的 Armbian 上同时运行 sing-box 和 WireGuard。旁路由本机可以解析内网域名，下游终端将其设为 DNS 服务器却始终超时。最终发现问题不在 DNS 匹配规则，而在 sing-box 向上游 DNS 发出的流量选错了出口接口。 本文示例地址均为重写后的示意值，不是原始网络配置；保留了私有网络的拓扑关系与协议行为。 网络拓扑与现象 角色 示例地址 作用 下游终端 192.168.10.20 DNS 客户端 旁路由 LAN 192.168.10.254 / eth0 sing-box DNS 监听地址 旁路由 WireGuard 10.77.0.11 / wg0 隧道客户端 内网 DNS 10.77.0.1:53 WireGuard 对端 DNS 拓扑如下： 终端 192.168.10.20 │ DNS 查询 ▼ 旁路由 192.168.10.254:53 (sing-box DNS 入站) │ 期望：由 wg0 向 10.77.0.1:53 查询 ▼ WireGuard 对端 DNS 10.77.0.1:53 内网测试域名采用 service.home.arpa（示例）。现象是： ...

在 Armbian 上部署 sing-box TUN 后，我遇到了一个不太直观的问题：IPv6 ping 能通，但开启 auto_redirect 后，IPv6 HTTPS 连接超时。 最终发现，故障并不在 IPv6 公网路由或代理节点，而是 Linux 回环接口 lo 缺少 ::1/128 地址。本文记录定位过程和修复方法。 环境 Linux：Armbian，ARM64，6.18 系列内核 sing-box：1.14.x 网络管理：Netplan + NetworkManager 透明代理：TUN，auto_route: true，auto_redirect: true IPv6：上游自动配置，接口已有全局 IPv6 地址和 RA 默认路由 为保护隐私，本文省略了真实公网地址、MAC、路由器地址、域名及自定义内部路由表编号。以下示例中的 ULA 地址和测试目标用于演示。 故障现象 直接测试 IPv6 HTTPS： curl --noproxy '*' -6 -v --connect-timeout 5 \ --resolve 'cloudflare.com:443:[2606:4700::6810:85e5]' \ https://cloudflare.com/ 开启 sing-box 后： * Trying [2606:4700::6810:85e5]:443... * Connection timed out after 5002 milliseconds curl: (28) Connection timed out 对照实验： ...

Docker 使用私有 CA（例如 step-ca）签发的 HTTPS 证书时，需要区分 Docker Engine 拉取镜像 和 容器内应用访问 HTTPS 两种场景。它们的证书信任库不一定相同。 一、Docker Engine 信任私有 CA 适用于 docker login、docker pull、docker push 访问私有镜像仓库。 仅信任指定 Registry（推荐） 假设 Registry 地址为 registry.example.com:5000： sudo mkdir -p /etc/docker/certs.d/registry.example.com:5000 sudo cp root_ca.crt /etc/docker/certs.d/registry.example.com:5000/ca.crt 目录名称应与实际访问的 Registry 主机名及端口一致；默认 HTTPS 443 端口通常可省略。ca.crt 应为 PEM 格式的 CA 证书，而不是私钥。 验证： docker login registry.example.com:5000 Ubuntu / Debian 宿主机全局信任 sudo cp root_ca.crt /usr/local/share/ca-certificates/my-root-ca.crt sudo update-ca-certificates Linux 上 Docker 通常会使用宿主机的系统 CA 信任库。通常不必重启 Docker；如果仍未生效，可检查 Docker 日志及证书配置，再决定是否重启（重启可能影响运行中的容器）。 ...

在 Linux 旁路由上同时运行 UFW 和 sing-box TUN 时，可能出现一种容易误判的故障：sing-box 本机运行正常，但局域网设备通过旁路由访问互联网失败。即使放行了当时被拦截的 TCP 端口，重启 sing-box 后问题也可能再次出现。 本文记录一种实际观察到的原因和待回归验证的修复方式。示例均使用文档保留地址，不对应真实网络。 环境和症状 Linux 旁路由，LAN 接口为 eth0，地址 192.0.2.1（仅作示例）。 下游终端 192.0.2.20，使用旁路由作为 IPv4 网关。 sing-box 的 TUN 接口名为 tun0，开启 auto_route 和 auto_redirect。 UFW 默认拒绝未经允许的入站流量。 sing-box 的关键配置： { "type": "tun", "interface_name": "tun0", "auto_route": true, "auto_redirect": true } 故障期间日志类似： [UFW BLOCK] IN=eth0 OUT= SRC=192.0.2.20 DST=192.0.2.1 PROTO=TCP DPT=24461 SYN DPT=24461 只是一次运行时观察到的动态端口，不应该把它永久写死在 UFW 里。OUT= 为空，提示包正在进入本机的 INPUT 路径，而不只是穿过 FORWARD 路径。 追踪 NAT 重定向 检查 sing-box 监听： sudo ss -lntup | grep sing-box 检查 nftables： ...

使用 CrowdSec 为 Debian 服务器实现恶意 IP 自动封禁 公网服务器每天都会遇到各种自动化扫描。 即使没有主动公开服务地址，SSH 端口也经常会收到针对 root、admin、test 等用户名的登录尝试。Web 服务则可能遭遇针对 .env、wp-admin、phpinfo.php 等路径的探测。 这些请求大多来自自动化扫描程序。虽然不一定构成实际入侵，但会产生大量无意义的日志，同时增加服务暴露面。 单纯依靠防火墙静态规则，难以根据攻击行为动态调整封禁名单。 因此，我选择尝试 CrowdSec，通过服务器日志识别恶意行为，再联动 nftables 自动封禁攻击来源。 本文记录在 Debian 12 上部署 CrowdSec 的过程，以及它如何判断一个 IP 是否应该被封禁。 一、CrowdSec 是什么？ CrowdSec 是一个开源的入侵检测与安全响应系统。 它通过分析 SSH、Web Server 等服务产生的日志，检测暴力破解、漏洞扫描、恶意爬虫等行为。 与传统的静态 IP 黑名单不同，CrowdSec 主要根据行为特征决定是否封禁，并且可以利用社区威胁情报。 CrowdSec 的工作可以分为两部分： Security Engine：读取日志，识别攻击，生成封禁决策。 Remediation Component（Bouncer）：执行封禁决策，例如修改防火墙规则。 两者相互独立。 也就是说，仅安装 CrowdSec Security Engine，并不会自动阻止网络连接。 1.1 工作流程 SSH / Caddy / Nginx | v Application Logs | v CrowdSec Parser | v Detection Scenarios | v Security Alerts | v Decision Profiles | v Local API | v Firewall Bouncer | v nftables | v Block IP CrowdSec 将日志分析与防火墙执行解耦，意味着它既可以在单台服务器上使用，也能通过中心 API 向多台服务器下发封禁决策。 ...