Welcome to CX’s Blog

Hugo 使用指南 适用版本：Hugo v0.168.0（Extended）。命令以 macOS/Linux 的 shell 为例。根据 Hugo 官方文档整理，主题私有配置以实际主题仓库为准。 1. 安装与版本检查 macOS（Homebrew）： brew install hugo hugo version hugo env Linux 可使用对应发行版软件包或 Hugo 官方发布的二进制文件。使用 SCSS/Sass 或某些主题资产管道时，需要确认安装版本包含 Extended 功能。 2. 创建项目 hugo new project myblog cd myblog git init 典型目录结构： myblog/ ├── archetypes/ # 新文章模板 ├── assets/ # 需通过资源管道处理的资源 ├── content/ # Markdown 内容 ├── data/ # 数据文件 ├── i18n/ # 主题界面翻译 ├── layouts/ # 自定义模板，可覆盖主题模板 ├── static/ # 原样复制到网站根路径 ├── themes/ # 本地主题或 Git 子模块 ├── hugo.toml # 网站配置（也可使用 YAML 等格式） └── public/ # 构建产物（运行 hugo 后生成） Hugo 本体不附带完整博客外观。若没有可用主题或自定义布局，可能出现 found no layout file for "html" 的警告。 ...

结论与验证状态 本次排查定位到：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 压力和内部流量回环；这些仅是排查方向，不能当作诊断结果。 ...

目标与环境 本地 OpenWrt 已有服务监听 127.0.0.1:3143，希望云服务器通过自身的 127.0.0.1:3143 访问这个服务。由 OpenWrt 主动建立 SSH 连接，适用于本地处于 NAT 后方的场景。 环境为 OpenWrt 23.05.2 x86_64，客户端使用 OpenSSH，云服务器运行 sshd。文中域名、用户和密钥路径均为示例，需要替换为实际值。 本次已确认反向隧道可用。后续观察到云服务器监听 :::3143，最终决定保留现有服务端设置。procd 配置是常驻运行方案，其重启和断网恢复仍应按本文步骤自行验收。 安装与前台验证 在 OpenWrt 上执行。 opkg update opkg install openssh-client /usr/bin/ssh -V 准备能无人值守登录云服务器的 SSH 密钥。示例私钥为 /etc/ssh/vps-3143_ed25519，对应公钥需安装到云服务器用户的 authorized_keys。首次连接时核对服务器 host key。已有可用密钥和 SSH Host 配置时，沿用实际配置即可。 /usr/bin/ssh -NT \ -i /etc/ssh/vps-3143_ed25519 \ -o ExitOnForwardFailure=yes \ -R 127.0.0.1:3143:127.0.0.1:3143 \ tunnel@example.com -R 的前一组地址是云服务器请求监听的地址，后一组地址是从 OpenWrt 访问的目标。此命令不会在 OpenWrt 上新建 3143 监听，本地已有服务应继续运行。云服务器上的对应监听端口需要空闲。 如果实际服务在其他 LAN 主机上，将右侧目标改为该主机地址，例如 -R 127.0.0.1:3143:192.168.10.20:3143。 在云服务器上验证。以下仅适用于 HTTP 服务，HTTPS 服务应使用实际域名、协议和证书配置。 ...

LibreSpeed 的 Go 后端内置 Web 界面，提供测量下载、上传和延迟的 HTTP 接口。本文用 systemd 在 Debian 上以非 root 身份运行后端，由同一台主机上的 Caddy 提供公网 HTTPS 入口。 安装 Debian 预编译二进制 本文固定使用 LibreSpeed speedtest-go v1.1.6，命令适用于 Debian amd64 和 arm64。发布包中的 speedtest-backend 已内置默认前端资源。其他架构可查看官方发布页。 sudo apt update sudo apt install curl ca-certificates ( set -eu version=1.1.6 arch=$(dpkg --print-architecture) case "$arch" in amd64|arm64) ;; *) printf 'Select a release archive for %s\n' "$arch" >&2; exit 1 ;; esac archive="speedtest-go_${version}_linux_${arch}.tar.gz" release="https://github.com/librespeed/speedtest-go/releases/download/v${version}" workdir=$(mktemp -d) trap 'rm -rf -- "$workdir"' EXIT cd "$workdir" curl -fsSL -o "$archive" "$release/$archive" curl -fsSL -o checksums.txt "$release/checksums.txt" awk -v file="$archive" '$2 == file || $2 == "*" file' checksums.txt > archive.sha256 sha256sum -c archive.sha256 tar -xzf "$archive" sudo install -d -m 0755 /usr/local/bin sudo install -m 0755 speedtest-backend /usr/local/bin/speedtest-backend ) 配置 systemd 服务 后端监听本机回环地址，由 Caddy 终止 TLS。database_type = "none" 关闭测速结果和统计记录。参见上游的 TOML 示例和 systemd unit。 ...

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

在一台内存较小的 Debian 服务器上，我原先使用 CrowdSec 分析 SSH 和 Web 日志，再通过 Firewall Bouncer 将封禁决策同步到 nftables。 这套方案能够根据攻击行为动态封禁 IP，但对于只有数百 MiB 内存、运行多个个人服务的服务器，资源开销需要重新权衡。最终我采用了以下组合： 网站：Caddy GeoIP 与手动 IP 白名单，按站点选择是否允许 CDN 回源豁免。 SSH：Fail2ban 读取 systemd journal，通过 nftables 封禁异常来源。 本文记录完整改造方法，以及部署过程中遇到的日志来源和启动时序问题。所有域名、地址和主机标识均已替换为示例。命令按 root 用户执行。 一、先明确防护能力的变化 项目 原方案 新方案 Web 访问控制 CrowdSec 分析日志并生成封禁决策 Caddy 按来源地区或 IP 放行 SSH 异常登录 CrowdSec SSH 场景 Fail2ban SSH jail Web 行为检测 取决于安装的 Collection 和 Scenario 本文没有保留 社区威胁情报 可使用 CrowdSec 社区名单 本文没有接入 Web 拒绝位置 Firewall Bouncer 的防火墙规则 Caddy HTTP 请求处理阶段 地区白名单不能等价替代行为检测。允许地区内的恶意请求仍可能到达应用，Caddy 的 GeoIP 规则也不会覆盖没有经过它的其他公网端口。 ...

初探、一見 1-進店篇 2-妹子篇 3-服務篇 4-感謝篇

Mac 与 iPhone 使用客户端证书访问 mTLS 网站 本文记录在 macOS 和 iPhone 上使用客户端证书访问内网 mTLS 网站的方法，涉及 CanoKey PIV、step-ca、Nginx 和 iOS 系统证书安装。 1. 环境与认证流程 当前环境： CA：已有的 CX-Homelab-CA Root CA 和 CX-Homelab-CA Intermediate CA。 证书签发：step-ca。 Web 服务器：Nginx 1.25.0。 测试站点：https://www.home.arpa。 Mac 客户端：CanoKey PIV 9A。 iPhone 客户端：通过 PKCS#12 文件导入客户端证书及私钥。 mTLS 与普通 HTTPS 的区别是：服务器验证客户端证书，客户端也需要验证服务器证书。客户端证书必须包含对应的私钥，单独安装 .crt 文件通常不足以完成客户端身份认证。 基本流程如下： 客户端访问 HTTPS 站点。 Nginx 请求客户端证书。 浏览器或系统选择客户端身份，并使用对应私钥完成 TLS 握手。 Nginx 验证客户端证书的有效性、证书链和用途。 验证通过后，服务器允许访问受保护的资源。 需要注意，客户端证书和服务器 CA 信任是两个不同的问题。安装客户端身份，并不意味着设备已经信任签发网站服务器证书的私有 CA。 2. Mac：使用 CanoKey PIV 9A 2.1 当前方案 Mac 使用 CanoKey 的 PIV 9A 槽保存客户端身份。macOS 通过智能卡相关机制识别证书和私钥，浏览器在 TLS 握手时使用该身份。 ...

macOS 与 iOS 使用客户端证书访问 mTLS 网站 本文介绍如何在 macOS 和 iOS 设备上配置客户端证书，以访问启用双向 TLS（mTLS）的 HTTPS 网站。示例使用私有 CA、step-ca、Nginx、PKCS#12 和 PIV 智能卡。文中的域名、证书名称、文件名和 IP 地址均为示例，请替换为自己的实际值。 1. mTLS 认证流程 普通 HTTPS 主要由客户端验证服务器证书；mTLS 还要求服务器验证客户端证书。 基本流程： 客户端访问 HTTPS 站点。 Nginx 在 TLS 握手期间请求客户端证书。 浏览器或系统选择客户端身份，并使用对应私钥完成签名。 Nginx 根据配置验证客户端证书、证书链和有效期。 验证通过后，连接进入 HTTP 层，由站点策略决定是否允许访问。 客户端身份和服务器 CA 信任是两个独立配置： 客户端身份：客户端证书及与之匹配的私钥，用于向服务器证明身份。 服务器 CA 信任：客户端信任签发网站服务器证书的 CA，用于验证 HTTPS 服务器身份。 安装客户端证书不会自动让设备信任私有 CA。 2. macOS：使用 PIV 硬件密钥 如果客户端私钥保存在支持 PIV 的硬件密钥中，可以让私钥留在硬件设备内，避免导出私钥文件。浏览器是否能使用该身份，取决于 macOS、智能卡中间件、密钥设备和浏览器的支持情况。 一般检查步骤： 插入 PIV 硬件密钥。 确认 macOS 能识别智能卡及其证书。 打开浏览器并访问 mTLS 网站。 如果浏览器请求客户端证书，选择对应的身份。 按提示输入 PIN 或完成硬件操作。 结合页面结果和服务器日志确认认证是否成功。 可用以下命令检查系统状态： ...

Git 的仓库认证与提交签名是两个独立环节：前者决定能否拉取、推送代码，后者让接收者验证提交由哪把密钥签署。本文使用两对独立的 FIDO2 SSH 密钥，将这两个用途分开管理。 Git 支持使用 SSH 密钥签署 Commit 和 Tag，因此只围绕 Git 开发时，可以直接使用 YubiKey 的 FIDO2 功能，无须额外部署 GnuPG。需要遵循 OpenPGP 验签流程的项目，则应按项目要求选择 GPG 签名。 ...