Nite

Go GMP 模型

nite@nite07.com (Nite) — Tue, 04 Aug 2026 03:10:52 +1000

GMP 是 Go 调度器的三个核心组件：

G（Goroutine，协程）：go func() 创建的任务。
M（Machine，机器）：操作系统线程。
P（Processor，处理器）：调度上下文，管理 G 队列。

M 就是内核级线程，由 runtime 通过 newm/newosproc（创建 M、创建线程的函数）调用系统接口创建，再交给 OS 调度到 CPU 上执行。M 是执行 Go 代码的最小单位，没有 P 的 M 只能休眠或处理系统调用。

G 的状态与生命周期

G 有明确的运行状态（runtime2.go 里的枚举）：

Gidle（空闲）：刚分配，还没初始化。
Grunnable（可运行）：在运行队列里排队，等 M 取。
Grunning（运行中）：正在执行用户代码。
Gsyscall（系统调用中）：执行 syscall，暂时脱离调度。
Gwaiting（等待中）：被 park（挂起），等 channel、锁、IO。
Gdead（已退出）：执行完，进 free 列表等待复用。

flowchart LR
    A["Gidle 空闲"] --> B["Grunnable 可运行"]
    B --> C["Grunning 运行中"]
    C --> D["Gsyscall 系统调用中"]
    C --> E["Gwaiting 等待中"]
    D --> B
    E --> B
    C --> F["Gdead 已退出"]
    F --> B

G 执行完后不直接销毁，而是进入空闲 G 缓存，等下次创建新 G 时复用。缓存分两级：每个 P 有一个本地缓存（pp.gFree），全局有一个共享缓存池（sched.gFree，加锁）。归还时先进 P 的本地缓存；创建新 G 时先从本地缓存取，本地缓存空了再去全局池一次搬 32 个补进来。一次搬一批是为了少碰全局锁：接下来 32 次创建都只从本地取。

复用的前提是栈能省则省。G 的栈会动态增长，执行完可能已经远大于起始大小。回收时栈大小不等于标准起始栈的，直接把栈释放；复用取出来发现栈不匹配，也释放重新分配。栈大小正好匹配的 G 才能连栈一起复用。

goroutine 栈起始只有 2KB（stackMin），远小于线程默认栈（MB 级），这是 G 轻量、能开几百万个的根本原因。栈不够用时动态增长，上限 1GB（64 位）。

队列结构

每个 P 有一个本地 G 队列，全局还有一个共享 G 队列。全局队列有锁保护（sched.lock，调度器锁），本地队列无锁，这是调度性能的关键。

flowchart TB
    GQ["全局 G 队列<br/>加锁保护"]
    P1["P1"]
    P2["P2"]
    P3["P3"]
    Q1["本地队列<br/>下个执行位 + 运行队列[256]"]
    Q2["本地队列"]
    Q3["本地队列"]
    M1["M1 内核线程"]
    M2["M2 内核线程"]
    M3["M3 内核线程（空闲）"]
    CPU["CPU 核心<br/>OS 调度"]
    GQ -->|取 G| Q1
    GQ -->|取 G| Q2
    GQ -->|取 G| Q3
    Q1 --- P1
    Q2 --- P2
    Q3 --- P3
    P1 --- M1
    P2 --- M2
    P3 -. 空闲 .-> M3
    M1 --> CPU
    M2 --> CPU

新 G 创建时优先放进当前 P 的本地队列，最优先的位置是 runnext（下个优先执行位，每个 P 一个单槽，可能为空）。runnext 空就直接占住；被占着就把旧的挤出去，放进 runq（本地运行队列）环形数组。runq 是固定长度 256 的数组，加 runnext 共容纳 257 个 G。

runnext 里放的是这几类 G：新建的 G（go func()）、被唤醒且需要尽快执行的 G（ready 传 next=true，比如 finalizer G）、被抢占让出的 G——让它 STW 结束后立刻续跑。

这是局部性原则：新 G 是当前 G 刚创建的，和它在同一 P 上运行，数据大概率还在 CPU 缓存里，立刻执行命中率最高。

本地队列放不下（runnext 被占且 runq 满 256）时，runqputslow（把一半 G 挪到全局队列的函数）把队首的一半（最早入队的 128 个 G）连同被挤出的旧 G（原本蹲在 runnext 里、还没轮到执行的 G）一起移到全局队列。移走旧的不移走新的：新 G 要马上执行，留在 runnext；队首的 G 等待最久，进全局队列后能被其他空闲 P 取走，顺带做了负载均衡。所以「P 的 G 队列长度最大值」是 256 + 1，不是无限。

为什么一次搬一半，不把旧 G 单独放全局？

疑问：新 G 占了 runnext，把被挤出的旧 G 丢进全局队列不就行了？为什么还要连队首一半（128 个 G）一起搬？

答案分两层：

旧 G 必须有个去处，runq 必须腾位置。 被挤出的旧 G 进不了 runnext（已被新 G 占住），只能进 runq，而 runq 已经满 256。所以从 runq 腾出空间是硬需求，队首的 G 必然要动。

一次搬一批是为了少碰全局锁。 全局队列有锁（sched.lock）。如果每次只腾 1 个位置：创建 G → runq 又满 → 又腾 1 个 → 又拿一次全局锁。goroutine 创建是热路径，每次创建都触发全局锁不可接受。一次搬 128 个，锁只拿一次，换来 runq 半空（128 个空位），接下来很多次入队都走无锁的本地路径，直到队列再次填满。搬一半也是留缓冲：runq 从 256 减到 128，新 G 不会立刻又顶满。

疑问：空闲 P 反正会 work stealing 来偷满队列，不搬不也行？

偷取本身有成本：多个空闲 P 同时盯上同一个满队列，会互相抢，抢输的只能重试，白白消耗 CPU。把一半搬进全局后，空闲 P 直接走 globrunqgetbatch 一次锁拿一批，不用抢。但 work stealing 只是兜底手段——队列满说明生产速度大于消费速度，靠别人来偷解决不了本 P 入队被堵的问题，腾位置是必须的。

所以搬一半的核心原因是「没地方放 + 不能每次创建都加锁」，负载均衡只是顺带收益。

P 和 M 的数量

P 的数量等于 GOMAXPROCS（最大处理器数），默认是 CPU 逻辑核心数。可以用 GOMAXPROCS 环境变量或 runtime.GOMAXPROCS(n) 修改。

M 的数量动态变化：有工作需要处理但空闲 M 不够时新建；空闲 M 进入休眠列表（sched.midle，空闲 M 链表）等待复用，长期空闲会被销毁。上限默认 10000，可以用 runtime/debug.SetMaxThreads（设置最大线程数）修改。

每个 M 同一时刻绑定 0 个或 1 个 P：持有 P 的 M 才能执行 Go 代码。M 通过绑定的 P 获取 G，顺序是 runnext → 本地队列 → 全局队列 → 偷其他 P。

复用线程

work stealing（工作窃取）

P 的本地队列空了，取 G 的顺序是：先全局队列（一次取一批，globrunqgetbatch，数量 min(128, 全局长度, 全局长度/GOMAXPROCS+1) 个，全局长度是全局队列当前排队的 G 数；除以 GOMAXPROCS 是为了平均分给每个 P，128 是本地队列放不下的上限），再网络轮询（netpoll，把数据就绪的 G 捡回来），还空就偷其他 P。

偷的时候从目标 P 的 runq 取队首的一半（runqgrab 里 n = n - n/2，从 head 开始数 n 个），也就是最早入队的那一半。偷不到、全局也空，P 进入空闲列表等待。P 的数量固定，不会销毁；会休眠或销毁的是 M。

取 G 还有一层公平性保护：每 61 次调度（schedtick%61 == 0）强制检查一次全局队列，有 G 就先取。防止两个 G 在本地队列里互相 spawn 出新 G，把全局队列里的 G 活活饿死。

hand off（交接）

G 阻塞分两种情况，处理方式不同：

普通阻塞（channel 通道、锁、sleep 睡眠）：G 被 park（挂起，暂停执行、等条件满足再唤醒），M 不换，继续从 P 的队列取下一个 G 执行。这时不需要新 M。
系统调用阻塞：M 带着 G 一起进入系统调用，P 被释放（handoffp，交接函数），从休眠 M 里唤醒一个接管这个 P，没有就新建。

系统调用返回时，M 先尝试要回 P：有闲 P 就直接继续执行 G；没有闲 P，G 被放进全局队列（globrunqput），M 进入休眠（stopm），等下次被唤醒。

负载均衡

每次新建 G（newproc，创建新 G 的函数）都会调用 wakep（唤醒 M 的函数）：如果当前没有自旋 M，且有空闲 P，就唤醒一个休眠 M 或新建 M，绑上这个 P，进入自旋模式去抢 G。

自旋 M 的取 G 顺序：本地队列（刚拿到的闲 P，队列本来就是空的）→ 全局队列 → 偷其他 P。

自旋 M 不会无限烧 CPU：

自旋 M 的数量有限制，最多是忙 P 数的一半（2 × 自旋M数 < GOMAXPROCS - 空闲P数 才允许新增）。
全局和所有 P 都找不到工作时，自旋 M 释放 P 回空闲列表，自己休眠（stopm → mPark，线程挂起），等下次 wakep 唤醒。

sysmon 与抢占

sysmon（系统监控线程）是 runtime 启动时创建的独立线程（newm 创建，跑 sysmon 函数），负责几件事：

抢占：最多每 10ms 检查一次，发现某个 G 在同一 P 上连续运行超过 10ms（forcePreemptNS，抢占时间阈值），就通过 SIGURG 信号（一个用于抢占的 Unix 信号）异步抢占（Go 1.14+）。G 让出 CPU 回到队列继续排队，之后还会被调度到。
syscall 接管：P 卡在系统调用里超过约 20us，sysmon 直接把 P 抢回来交给别的 M（配合 hand off）。
网络轮询兜底：超过 10ms 没人轮询网络事件，sysmon 自己轮一次 epoll，把就绪的 G 唤醒。
定时 GC：forcegcperiod（2 分钟）没触发过 GC 就强制触发一次。

网络 IO 与 netpoll

网络 IO（socket 读写）在 Go 里默认走非阻塞模式，底层是 epoll（Linux）/ kqueue（macOS）这类 IO 多路复用。G 发起的读写没就绪时，netpollblock 里 gopark 挂起（waitReasonIOWait），不占 M。就绪事件由 netpoll 收集，把对应 G 唤醒塞回队列。

所以大量 goroutine 同时做网络 IO 时，M 不会被 IO 阻塞。这是 GMP 支撑高并发网络服务的核心：连接数再多，活跃线程也就 GOMAXPROCS 上下。

注意区分：文件 IO、syscall 阻塞走另一条路（hand off，占 M），网络 IO 走 netpoll，不占 M。

调度流程

go func(){...}()：创建 G，优先放当前 P 的 runnext，其次本地队列；本地队列满 256 时，队首一半 G 连同挤出的旧 G 一起移到全局队列。
M 从绑定的 P 取 G：runnext → 本地队列 → 全局队列 → 偷其他 P。
G 阻塞：普通阻塞 M 继续取下一个 G；系统调用阻塞则交接 P 给其他 M。
系统调用返回：G 重新入队，M 抢 P 或休眠。

flowchart LR
    A["go func()"] --> B["创建 G"]
    B --> C{"P 本地队列满？"}
    C -- 否 --> D["放下个执行位 / 本地队列"]
    C -- 是 --> E["队首一半 G + 挤出的旧 G 移到全局队列"]
    D --> F["M 从 P 取 G 执行"]
    E --> F
    F --> G{"G 阻塞？"}
    G -- 普通阻塞 --> H["挂起 G，M 继续执行下一个 G"]
    G -- 系统调用 --> I["交接 P 给其他 M"]
    H --> F
    I --> F

P 的状态

P 有四种状态（runtime2.go）：

Pidle（空闲）：在空闲 P 列表里，队列为空，等着被 M 领走。
Prunning（运行中）：被某个 M 持有，正在执行 G。
Pgcstop（GC 停止）：GC 的 STW（stop the world，暂停所有线程）阶段，所有 P 停在这里。
Pdead（已销毁）：GOMAXPROCS 调小时多余的 P 被销毁，调大时还能复用。

GC 开始时 STW：所有 M 跑到安全点，P 转 Pgcstop，调度暂停。标记阶段并发进行，P 恢复跑用户代码。GC 的完整原理见 Go GC 机制。

M0 和 G0

M0 是程序启动后的第一个 M（主线程），负责初始化（安装信号处理、创建 sysmon 线程等），且永不退出——mexit（线程退出流程）里对 m0 是 wedge（钉住，卡住不动），直到进程结束。

G0 是每个 M 的专属调度 goroutine。每次创建 M（allocm，创建 M 的函数）都会同时创建它的 g0，存在 M 的 g0 字段里。g0 不进任何队列、不占 P，只负责执行调度代码（schedule 调度、栈增长、信号处理等）。它独立于 P，只和 M 关联：M 阻塞时 g0 跟着 M 走，没有「g0 放哪里」的问题。

也不存在「m0 和 g0 解绑」：g0 永远属于 m0，m0 通过 g0 进入调度循环。

Hello world 执行流程

程序启动，创建 m0 和它的 g0。
g0 执行 schedinit（调度器初始化）：创建 GOMAXPROCS 个 P、初始化全局队列。
newproc 创建 main goroutine，放入某个 P 的本地队列。
m0 的 g0 进入调度循环，取出 main goroutine，m0 转而执行它。
main 执行完毕，程序退出。

runtime/trace

import "runtime/trace"

f, _ := os.Create("trace.out")
trace.Start(f)
defer trace.Stop()

// 业务代码

生成后用 go tool trace trace.out 打开 Web UI（网页界面），可以看 G/P/M 的调度、阻塞、系统调用、GC 等事件。

自部署 Gitea 被爬虫打爆流量的缓解措施

nite@nite07.com (Nite) — Sun, 02 Aug 2026 18:19:54 +1000

现象

自部署的 Gitea 某天流量开始异常。服务器商控制面板里，流量额度以肉眼可见的速度消耗，月流量包很快见底。访问日志按响应大小聚合后，git 域名占了绝大多数流量，其中 /owner/repo/compare/ 这类版本对比页面是大头，单页最大响应能到 10MB 级别。

爬虫特征明显：Amazonbot、Lightpanda，以及一批伪造旧版 Chrome/Firefox UA 的轮换 IP，反复抓取 blame、compare 页面。大量独立 IP 各自只请求一两次，典型的分布式爬取。

原因

爬虫 UA 复杂，既有知名爬虫（Amazonbot、Lightpanda），也有伪造浏览器 UA 的轮换 IP。
重型页面单页体积大，compare 页面最大超过 10MB，且完全不压缩，爬虫每抓一页都是大流量。
单 IP 限流对轮换 IP 池无效，绝大多数 IP 只请求一两次就换下一个。

方法

1. Caddy 配置

UA 黑名单（@block_bots 命中直接 403）和重型页面限流（@heavy 单 IP 2 次/10s）都写在同一个站点块里，按顺序执行。UA 名单覆盖常见爬虫和扫描器，可以按需增删：

git.example.com {
	# 日志配置：按域名输出访问日志
	import log git.example.com

	# 1. UA 黑名单：命中的爬虫直接 403
	@block_bots header_regexp User-Agent "(?i)(SemrushBot|Lightpanda|GPTBot|ClaudeBot|Bytespider|AhrefsBot|MJ12bot|DataForSeoBot|Amazonbot|DotBot|CCBot|cohere-ai|Diffbot|Google-Extended|Meta-ExternalAgent|Meta-ExternalFetcher|Applebot-Extended|Timpibot|ImagesiftBot|Crawl4AI|Scrapy|ChatGLM-Spider|DeepSeekBot|cohere-training-data-crawler|AI2Bot|TikTokSpider|omgili|BLEXBot|Exabot|360Spider|80legs|MegaIndex|Barkrowler|DataCha0s|Nikto|Nmap|Nessus|OpenVAS|Sqlmap|WPScan|Nuclei|Masscan|Shodan|Acunetix|Dirbuster|Whatweb|Havij|Fimap|Jbrofuzz|Zgrab|Censys)"
	handle @block_bots {
		respond 403
	}

	# 2. 重型页面（compare/blame 等）单 IP 限流
	@heavy path_regexp heavy_path ^/[^/]+/[^/]+/(?:compare|blame|commit|commits|archive|pulls|issues)(?:/|$)
	handle @heavy {
		rate_limit {
			zone dynamic_zone {
				key {client_ip}
				events 2
				window 10s
			}
			log_key
		}
		reverse_proxy 100.64.0.10:3000
	}

	# 3. robots.txt：礼貌爬虫先读规则
	handle /robots.txt {
		respond `User-agent: *
Disallow: /blame/
Disallow: /compare/
Disallow: /commit/
Disallow: /commits/
Disallow: /archive/
Disallow: /pulls/
Disallow: /issues/`
	}

	# 4. 其余请求反代到 Gitea
	reverse_proxy 100.64.0.10:3000
}

@heavy 的路径规则同时覆盖 compare、blame、commit 等几类重型页面，单个 IP 在 10 秒内超过 2 次就返回 429。log_key 开启后，被限流的请求会在访问日志里记下对应的 IP，方便调阈值。

2. Gitea 开启源站 gzip

改 app.ini 的 [server] 段，加一行后重启 Gitea：

[server]
ENABLE_GZIP = true

ENABLE_GZIP 只压缩运行时生成的内容，静态资源不受影响。放在源站而不是反代层，是因为链路是「源站 → 反代 → 访客」两段，双向计费下源站压缩两段都省；只在反代压只省一段。Caddy 的 reverse_proxy 会替缺省客户端补 Accept-Encoding: gzip 并原样透传上游的压缩响应，不需要在 Caddy 侧再配 encode。

参考链接

Gitea custom template 内联脚本被 CSP nonce 拦截

nite@nite07.com (Nite) — Sun, 02 Aug 2026 02:03:49 +1000

现象

把 Matomo 统计脚本放进 $GITEA_CUSTOM/templates/custom/header.tmpl（渲染在 </head> 之前）后，页面里始终没有统计数据。浏览器控制台报：

Executing inline script violates the following Content Security Policy directive 'script-src * 'nonce-<random>''. Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required to enable inline execution. The action has been blocked.

原因

Gitea 1.27.0 把 CSP 的内联脚本策略改成了 per-request nonce（PR #37232）：每个响应生成一个随机 nonce，script-src 变成 * 'nonce-xxx'，外部脚本照常放行，但内联 <script> 只有带上这个 nonce 才会执行。custom template 里的内联脚本没有 nonce 属性，直接被浏览器拦掉。1.27.0 的发布说明也提示了这点：custom templates 里注入的内联 <script> 需要更新后才能继续执行。

解决

给 script 标签加上 nonce 属性，值用模板变量 {{ctx.CspScriptNonce}}：

<script nonce="{{ctx.CspScriptNonce}}">
  // 你的内联脚本，例如 Matomo 统计代码
</script>

保存后重启 Gitea（容器部署直接重启容器），刷新页面，控制台不再报 CSP 拦截错误，统计面板里能看到访客。

Goldberg Steam Emulator 补丁流程

nite@nite07.com (Nite) — Sun, 26 Jul 2026 12:30:00 +1000

Goldberg Steam Emulator（GSE）通过替换游戏的 steam_api(64).dll，让游戏不依赖 Steam 客户端也能运行。游戏调 Steam API 时实际走的是模拟器，模拟器返回伪造响应，游戏以为 Steam 在跑。

原版项目已经不怎么更新了，社区现在主要用 GBE Fork，一个活跃维护的分支。另外还需要 Steamless 来去除 exe 自带的 DRM。

1. 用 Steamless 处理 exe

Steamless 去掉的是 exe 上的 SteamDRM Wrapper（也叫 Steam Stub）。无论 exe 有没有被加密，都可以直接跑一次 Steamless——没 DRM 的文件会被安全跳过，不会损坏。

下载 Steamless 之后，打开 Steamless.exe，选游戏主 exe，点解包。处理完会在同目录生成一个 .unbind 文件。原 exe 备份一下，把 .unbind 重命名成原 exe 的名字替换就行。

大 exe（超过 100MB）可能要花几分钟。

2. 找 steam_api(64).dll

在游戏文件夹里搜 steam_api*.dll。

结果有两种情况。

只有一个 DLL： 通用/Unity 引擎游戏，替换这个 DLL，steam_settings 文件夹放它旁边。

有两个 DLL（Unreal Engine 游戏）：

<GameDir>\Engine\Binaries\ThirdParty\Steamworks\Steamv157\Win64\steam_api64.dll
<GameDir>\<GameName>\Binaries\Win64\steam_api64.dll

UE 引擎启动时从 Engine 目录加载 steam_api64.dll，不是从游戏主目录。替换 Engine 目录的那个，steam_settings 也放 Engine 目录。游戏主目录的 DLL 保持原版，不要动。

3. 备份原版 DLL

找到要替换的 DLL 之后，复制一份，重命名成 steam_api64.dll.old。后续生成接口文件要用到这个备份。

4. 替换成模拟器 DLL

从 GBE Fork 发布包里，把对应架构的 DLL 复制过去覆盖原版：

64 位游戏：regular\x64\steam_api64.dll
32 位游戏：regular\x86\steam_api.dll

模拟器 DLL 大约 7–11MB，原版大约 200–400KB，差别很明显。

如果是 UE 引擎游戏，游戏主目录的 DLL 保持原版不动。

5. 创建 steam_settings 目录

在模拟器 DLL 同级创建一个 steam_settings 文件夹。UE 引擎放 Engine 目录，通用引擎放游戏 exe 同级。

6. 放 steam_appid.txt

在 Steam 商店页面的 URL 里找 AppID：store.steampowered.com/app/<数字>/。

新建 steam_settings\steam_appid.txt，只写纯数字 AppID。比如 3683770。

7. 生成 steam_interfaces.txt（推荐）

接口版本不匹配会导致崩溃或功能缺失。用 GBE Fork 里自带的 generate_interfaces_x64.exe（或 x86 版），对备份的原版 DLL 跑一次。

把备份的 steam_api64.dll.old 拖进工具窗口就行。工具会在当前目录生成 steam_interfaces.txt，把它移到 steam_settings\ 里。

必须对原版 DLL 跑，不能用模拟器 DLL。

8. 可选：配置 INI 文件

steam_settings.EXAMPLE\ 里有模板，按需复制到 steam_settings\，去掉 .EXAMPLE 中缀。

关键配置：

configs.user.ini：local_save_path=./path/relative/to/dll，让存档存到游戏目录而非全局 %appdata%
configs.user.ini：account_name=Player，改游戏里显示的名字
configs.user.ini：language=english，语言
configs.main.ini：offline=0，离线模式
configs.app.ini：unlock_all=1，解锁所有 DLC

不配 INI 也行，模拟器有合理的默认值。

常见问题

游戏闪退或无法启动，按这个顺序排查：exe 有没有跑过 Steamless，DLL 有没有换对位置（UE 引擎看仔细），steam_settings 是否和 DLL 同级，steam_interfaces.txt 是否从原版 DLL 生成。

默认存档在 %appdata%\GSE Saves\。想改成游戏目录本地存档，在 configs.user.ini 里设 local_save_path。

UE 引擎游戏只替换 Engine 目录的 DLL，游戏主目录的 DLL 不要动。steam_settings 也放 Engine 目录。

恢复原版：把 steam_api64.dll.old 改回 steam_api64.dll，删掉 steam_settings 文件夹和 steam_appid.txt。

steam_interfaces.txt 生成在运行工具的当前目录，不是工具本身的位置。建议先切到模拟器 DLL 所在目录再跑，生成的文件直接移到 steam_settings\。

自动化工具

不想手动操作的话，有两个社区工具：

ARMGDDN Autocracker，基于 GBE Fork，装好后在游戏文件夹上右键就能自动完成补丁。仓库： https://github.com/KaladinDMP/ARMGDDN-Autocracker。作者 GitHub 账号曾被封过，最新版可能要从 Telegram 找。

SteamAutoCracker，内置调用 Steamless 和 Goldberg，一键处理 DRM 去除和 DLL 替换。仓库： https://github.com/BigBoiCJ/SteamAutoCracker。

用 vnStat 和 picosnitch 持续统计 Linux 流量

nite@nite07.com (Nite) — Thu, 23 Jul 2026 11:00:00 +1000

VPS 的流量异常时，通常要回答两个问题：哪个网卡在什么时候跑了多少流量，以及到底是哪个服务跑掉的。

vnStat 记录网卡接口的收发流量，适合看总出口和按小时、天、月的趋势。picosnitch 记录每个可执行文件发起的连接，能继续查到进程、域名、端口和收发字节数。两个工具都在后台持续写数据，但统计维度不同，放在一起正好补全。

vnStat：按网卡统计

vnStat 不是抓包工具。它读取内核提供的网卡计数器，vnstatd 定时将数据写入数据库，资源占用很低。它会保存 5 分钟、小时、天、月和年的统计记录。

Arch Linux 安装并启动服务：

sudo pacman -S vnstat
sudo systemctl enable --now vnstat

服务首次启动时会为当前可用网卡创建数据库记录。先看已记录的接口：

vnstat --dbiflist

之后新增的接口可以手动加入，例如 Tailscale 创建了 tailscale0：

sudo vnstat --add -i tailscale0

常用的总览查询：

# 默认摘要：今天、当前月、累计
vnstat -i wlan0

# 短格式摘要
vnstat -i wlan0 -s

# 一行可解析输出，适合脚本
vnstat --oneline -i wlan0

# 最近 7 天、12 小时、最近月份
vnstat -i wlan0 -d 7
vnstat -i wlan0 -h 12
vnstat -i wlan0 -m

要查异常发生的时间段，--begin 和 --end 可以配合每日、每小时或 5 分钟列表使用。指定 --end 后，列表末尾会多出一行 sum，就是整个区间的上下行合计。

# 每日统计和区间合计
vnstat -i wlan0 -d --begin 2026-07-20 --end 2026-07-31

# 一天内按小时查，时间精确到分钟
vnstat -i wlan0 -h --begin "2026-07-28 08:00" --end "2026-07-28 20:00"

# 高峰时段按 5 分钟查
vnstat -i wlan0 -5 --begin "2026-07-28 12:00" --end "2026-07-28 14:00"

--begin 支持 YYYY-MM-DD HH:MM、YYYY-MM-DD 和 today；--end 支持前两种日期格式。它们只能和列表输出、JSON 或 XML 一起使用。

脚本需要原始字节数时用 JSON：

vnstat -i wlan0 -d --begin 2026-07-28 --end 2026-07-30 --json \
  | jq '.interfaces[0].traffic.days'

实时查看速率和生成图表：

# Ctrl+C 后会显示本次运行期间的统计
vnstat --live -i wlan0

# 最近 24 小时的终端条形图
vnstat -i wlan0 -hg

# 每日统计渲染为 PNG
vnstati -i wlan0 -d -o ~/wlan0.png

默认只保留 48 小时的 5 分钟粒度数据。要更久地保留高峰时段的细粒度记录，修改 /etc/vnstat.conf 中的 5MinuteHours，然后重启服务：

5MinuteHours 336

sudo systemctl restart vnstat

vnStat 从 vnstatd 开始运行后才有数据，无法补回此前经过网卡的流量。

picosnitch：按进程统计

vnStat 能发现哪段时间的总流量增长，但无法说明流量属于谁。picosnitch 是使用 BPF 和 fanotify 的用户态 daemon，按可执行文件记录网络连接，同时写入 SQLite。它会记录可执行文件路径和哈希、父进程、域名、端口、用户，以及收发字节数；容器内的应用也能识别。

picosnitch 上游推荐用全局 pipx 安装。Arch Linux 可以这样部署：

sudo pacman -S python-pipx
sudo pipx install picosnitch --global
sudo picosnitch systemd
sudo systemctl enable --now picosnitch

需要 Python 3.12 或更高版本，以及能运行现代 libbpf CO-RE 程序的 Linux 内核。

数据有三种查看方式：

# 终端 TUI，浏览历史连接
picosnitch tui

# Web UI，默认监听 http://localhost:5100
picosnitch webui

# 实时事件流
sudo picosnitch top

配置在 /etc/picosnitch/config.toml。本地 SQLite 数据库默认位于 /var/lib/picosnitch/picosnitch.db，默认保留 30 天。需要延长历史记录时修改 retention_days，改完重启服务：

[database]
retention_days = 90

sudo systemctl restart picosnitch

Web UI 默认只监听本机。需要让局域网或反代访问时，可以在启动前设置监听地址和端口；公开暴露前应自行做好访问控制：

PICOSNITCH_HOST=0.0.0.0 PICOSNITCH_PORT=5100 picosnitch webui

一起排查流量异常

先用 vnStat 查实际经过网卡的流量，确定异常从哪天或哪个小时开始。时间范围收窄后，打开 picosnitch 的 TUI 或 Web UI，按对应时间查看可执行文件、域名和端口。

例如，vnStat 显示 wlan0 在中午两小时内发送流量异常增长，接着在 picosnitch 中查看同一时间范围。如果流量集中在 caddy，再看它连接到哪些客户端；如果集中在备份程序或下载器，就从对应服务的日志和配置继续排查。网卡统计负责发现问题，进程统计负责定位来源。

修复 WSL2 Arch Linux 里 Podman build 的 newuidmap 报错

nite@nite07.com (Nite) — Sat, 11 Jul 2026 20:23:42 +1000

在 Windows 上的 WSL2 Arch Linux 里跑 rootless Podman，构建镜像时可能直接卡在 user namespace 初始化阶段：

podman build . -t game-crawler:latest

报错类似这样：

WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers
ERRO[0000] running `/usr/sbin/newuidmap 61029 0 1000 1 1 100000 65536`: newuidmap: Could not set caps
Error: cannot set up namespace using "/usr/sbin/newuidmap": should have setuid or have filecaps setuid: exit status 1

"/" is not a shared mount 只是 warning。这里真正让 build 失败的是 newuidmap: Could not set caps。

触发条件

这是 rootless Podman 的问题，不是 Dockerfile 本身的问题。

Podman 官方的 rootless tutorial 里写到，rootless Podman 需要 /etc/subuid 和 /etc/subgid 里的 subordinate UID/GID 范围。newuidmap(1) 的手册也说明，它负责设置 user namespace 的 UID 映射，并会检查调用者是否被 /etc/subuid 授权。

也就是说，rootless Podman 创建容器命名空间时，需要这两个辅助程序：

/usr/bin/newuidmap
/usr/bin/newgidmap

在 Arch Linux 里它们来自 shadow 包。如果二进制没有 setuid，也没有对应 file capability，普通用户就没有权限完成 UID/GID 映射，Podman build 会在创建 namespace 时失败。

检查当前状态

先看文件权限和 capability：

stat -c '%A %U:%G %a %n' /usr/bin/newuidmap /usr/bin/newgidmap
getcap /usr/bin/newuidmap /usr/bin/newgidmap

出问题时可能是这样：

-rwxr-xr-x root:root 755 /usr/bin/newuidmap
-rwxr-xr-x root:root 755 /usr/bin/newgidmap

getcap 没有任何输出。

再确认当前用户有 subordinate ID：

grep "^$USER:" /etc/subuid /etc/subgid

正常应该有类似输出：

/etc/subuid:nite:100000:65536
/etc/subgid:nite:100000:65536

如果这里没有当前用户的记录，需要先补 /etc/subuid 和 /etc/subgid。如果这里已经有记录，但 newuidmap/newgidmap 没有 setuid 或 capability，那就继续修权限。

用 file capability 修复

优先给两个辅助程序加最小 capability：

sudo setcap cap_setuid=ep /usr/bin/newuidmap
sudo setcap cap_setgid=ep /usr/bin/newgidmap

检查结果：

getcap /usr/bin/newuidmap /usr/bin/newgidmap

应该看到：

/usr/bin/newuidmap cap_setuid=ep
/usr/bin/newgidmap cap_setgid=ep

Arch 里 /usr/sbin 通常是指向 bin 的链接，所以报错路径即使写的是 /usr/sbin/newuidmap，修 /usr/bin/newuidmap 也是同一个文件。

验证 rootless namespace

不用完整 build。先用 podman unshare 验证 UID/GID 映射能不能建起来：

podman unshare sh -c 'echo uid_map:; cat /proc/self/uid_map; echo gid_map:; cat /proc/self/gid_map'

修好后会看到类似：

uid_map:
         0       1000          1
         1     100000      65536
gid_map:
         0       1000          1
         1     100000      65536

这里的 1000 是当前 WSL 用户的 UID，100000 65536 来自 /etc/subuid 和 /etc/subgid。

然后重新 build：

podman build . -t game-crawler:latest

如果 setcap 不可用

先确认 setcap/getcap 是否存在：

command -v setcap getcap

如果没有，安装提供它们的包：

sudo pacman -S libcap

还有一种传统做法是给 newuidmap/newgidmap 加 setuid：

sudo chmod u+s /usr/bin/newuidmap /usr/bin/newgidmap

检查：

stat -c '%A %U:%G %n' /usr/bin/newuidmap /usr/bin/newgidmap

期望看到 -rwsr-xr-x。如果 file capability 可用，优先用 setcap，权限范围更窄。

修复 Arch Linux WSL2 中无法调用 Windows 程序的问题

nite@nite07.com (Nite) — Thu, 09 Jul 2026 16:33:30 +0800

什么是 WSL Interop

WSL Interop 是 WSL2 的核心功能之一，允许你在 WSL 终端中直接调用 Windows 可执行文件。例如：

powershell.exe -NoProfile -Command "Get-Process | Select-Object -First 5"
winget.exe search nushell
explorer.exe .

Windows 文件系统也通过 /mnt/c/、/mnt/d/ 等路径挂载，可以直接读写。

问题

在 Arch Linux WSL2 中，有时会发现以上命令全部失效，报错为"exec format error"或"未找到命令"。这是因为 WSL Interop 的注册依赖 systemd-binfmt.service，而该服务在 Arch Linux 上会因条件检查未满足而被跳过——Arch 不像 Ubuntu 那样预置 binfmt.d 配置文件。

修复

在 WSL 终端中执行：

sudo mkdir -p /etc/binfmt.d
sudo tee /etc/binfmt.d/wsl-interop.conf > /dev/null << 'EOF'
:WSLInterop:M::MZ::/init:P
EOF

然后重启服务：

sudo systemctl restart systemd-binfmt

验证

# 检查服务状态，应为 active (exited) 而非 skipped
systemctl status systemd-binfmt

# 检查 WSLInterop 已注册
cat /proc/sys/fs/binfmt_misc/WSLInterop

# 测试调用 Windows 程序
powershell.exe -NoProfile -Command "Write-Output 'interop OK'"

该配置文件是持久化的，每次 WSL 启动时自动生效，无需重复操作。

给 Podman 邮局配置 Fail2Ban：用 UFW 封禁 SASL 暴力破解

nite@nite07.com (Nite) — Thu, 09 Jul 2026 15:30:00 +0800

我的自建邮局（Postfix + Dovecot）跑在 netcup VPS 的 rootless Podman 容器里。查看 Postfix 日志摘要时，24 小时内有 2477 封邮件被拒，其中 2471 封来自同一 IP；同时出现了 152 次 SASL LOGIN 认证失败，以及扫描、中继滥用和 TLS 探测。

Postfix 自己可以拒绝垃圾邮件，但 SASL 密码猜测是另一类问题。Fail2Ban 能从日志里识别重复失败的来源，再让防火墙封禁 IP。服务器已经用 UFW 管理入站规则，因此这里不让 Fail2Ban 直接写 iptables，而是使用它内置的 ufw action。

环境

项目	值
宿主机	Arch Linux
容器运行时	Podman rootless
邮局镜像	`ghcr.io/docker-mailserver/docker-mailserver:latest`
邮局服务	`systemd-mailserver`
Quadlet 文件	`~/pod/docker-mailserver/mailserver.container`
宿主机邮件日志	`~/pod/docker-mailserver/logs/mail.log`
容器内邮件日志	`/var/log/mail/mail.log`
Fail2Ban	1.1.0
防火墙	UFW

1. 安装并检查现有状态

安装并启动 Fail2Ban：

sudo pacman -S fail2ban
sudo systemctl enable --now fail2ban

先确认 UFW 已启用、Fail2Ban 正在运行，以及当前启用的 jail：

sudo ufw status verbose
sudo systemctl is-active fail2ban
sudo fail2ban-client status

这里应看到 UFW 的 Status: active。完成配置后，jail 列表会包含：

Status
|- Number of jail:  3
`- Jail list:       postfix, postfix-sasl, sshd

backend 与 banaction 是两个不同的设置：

backend 决定 Fail2Ban 从哪里读取失败记录，例如 journald 或普通日志文件。
banaction 决定命中阈值后怎样封禁 IP。

这个邮件容器将日志写到宿主机挂载文件，所以邮件 jail 要使用 backend = polling；切换到 UFW 不会改变日志读取方式。

2. 让 Postfix jail 读取容器日志

传统安装的 Postfix 日志通常在 /var/log/mail.log。容器里的这个路径对宿主机 Fail2Ban 不可见，应该填写宿主机 Volume 挂载后的真实路径。

Arch 的 Fail2Ban 默认会通过 paths-arch.conf 为 Postfix 选择 systemd 日志后端。这里的日志是文件，因此在本地覆盖配置里明确设置 polling。

创建或编辑 /etc/fail2ban/jail.d/mailserver.local：

[DEFAULT]
postfix_backend = polling
postfix_log = /home/nite/pod/docker-mailserver/logs/mail.log

[postfix-sasl]
enabled   = true
mode      = auth
port      = smtp,465,submission,imap,imaps,pop3,pop3s
logpath   = /home/nite/pod/docker-mailserver/logs/mail.log
backend   = polling
maxretry  = 5
findtime  = 10m
bantime   = 1h
banaction = ufw

[postfix]
enabled   = true
mode      = more
port      = smtp,465,submission
logpath   = /home/nite/pod/docker-mailserver/logs/mail.log
backend   = polling
maxretry  = 5
findtime  = 10m
bantime   = 1h
banaction = ufw

文件后缀要用 .local。Fail2Ban 依次读取 jail.conf、jail.d/*.conf、jail.local、jail.d/*.local，这个本地文件会在最后覆盖默认值。

3. 将 sshd 的封禁 action 改为 UFW

不要编辑 /etc/fail2ban/jail.conf，它由软件包提供，更新时可能被覆盖。

如果希望默认 jail 都使用 UFW，编辑 /etc/fail2ban/jail.local，在 [DEFAULT] 中设置：

[DEFAULT]
banaction = ufw
banaction_allports = ufw

若只想切换 SSH jail，也可以只写：

[sshd]
banaction = ufw

Postfix 和 postfix-sasl 已在 mailserver.local 中各自指定 banaction = ufw，不会依赖这个全局设置。

Fail2Ban 自带的 UFW action 会调用 ufw 添加和删除规则。这样不需要再通过 iptables -L 查 Fail2Ban 的封禁链，直接查看 UFW 即可。

4. 先检查配置，再重启 jail

编辑完成后先解析配置：

sudo fail2ban-client -d >/dev/null

这条命令只检查解析结果，不修改防火墙。

切换 action 后应完整重启服务：

sudo systemctl restart fail2ban

5. 验证日志、action 和 UFW 规则

确认邮件 jail 正在读取宿主机日志：

sudo fail2ban-client status postfix-sasl
sudo fail2ban-client status postfix

输出中的 File list 应为：

/home/nite/pod/docker-mailserver/logs/mail.log

不实际封禁的情况下，可以测试 SASL 过滤器是否匹配已有日志：

sudo fail2ban-regex /home/nite/pod/docker-mailserver/logs/mail.log "postfix[mode=auth]"

服务重启后，检查运行时 action，而不是只看配置文件：

sudo systemctl is-active fail2ban
sudo fail2ban-client get sshd actions
sudo fail2ban-client get postfix actions
sudo fail2ban-client get postfix-sasl actions

本次实际输出：

active
The jail sshd has the following actions:
ufw
The jail postfix has the following actions:
ufw
The jail postfix-sasl has the following actions:
ufw

6. 做一次端到端测试

sudo fail2ban-client set sshd banip 192.0.2.1
sudo ufw status numbered | grep -F 192.0.2.1
sudo fail2ban-client set sshd unbanip 192.0.2.1

第二条命令应显示带有 by Fail2Ban 注释的 UFW 规则；第三条命令会立即删除测试封禁。

参考

隐藏 WSL2 开机自启的控制台窗口

nite@nite07.com (Nite) — Thu, 09 Jul 2026 02:00:00 +0800

WSL2 在所有终端窗口关闭后会自动停止实例。虽然可以通过 .wslconfig 设置 vmIdleTimeout=-1 和 instanceIdleTimeout=-1 来缓解，但部分版本仍然会出现实例被终止的情况。一个可靠的方案是在登录时启动一个常驻进程来保持实例运行，但直接通过任务计划程序运行 wsl.exe 会弹出一个黑色控制台窗口。本文介绍用 VBS 脚本包装来隐藏这个窗口。

创建 VBS 启动脚本

在 Windows 上创建一个 VBS 脚本文件，例如 C:\Users\你的用户名\start-wsl.vbs，内容如下：

Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "wsl.exe -d archlinux -u root /bin/bash -c ""sleep infinity""", 0, False

将 archlinux 替换为你的 WSL 发行版名称（可在 PowerShell 中执行 wsl -l 查看）。

WshShell.Run 的参数说明：

第二个参数 0 — 隐藏窗口，不显示任何界面
第三个参数 False — 不等待子进程结束，脚本立即退出

创建计划任务

在 PowerShell 中执行以下命令，创建一个在登录时自动运行的计划任务：

$action = New-ScheduledTaskAction -Execute "wscript.exe" -Argument '"C:\Users\你的用户名\start-wsl.vbs"'
$trigger = New-ScheduledTaskTrigger -AtLogOn
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -ExecutionTimeLimit (New-TimeSpan -Seconds 0)
Register-ScheduledTask -TaskName "WSL2 AutoStart" -Action $action -Trigger $trigger -Settings $settings

验证

注销并重新登录（或重启），在 PowerShell 中执行 wsl -l --running 确认 WSL 实例已启动。整个过程中不会出现任何控制台窗口。

mihomo TUN 模式断网：ip_forward、UFW 与 auto-redirect

nite@nite07.com (Nite) — Tue, 30 Jun 2026 03:15:00 +1000

mihomo 用 TUN 模式（stack: system，auto-route: true）时，启动后全局断网，SSH 也掉线。问题不在 mihomo 配置本身，而是系统网络转发设置没配齐。

原因

stack: system 让 mihomo 依赖内核网络栈转发 TUN 流量。auto-route: true 会接管默认路由，把所有流量导入 TUN 网卡。但内核转发需要满足三个条件：

net.ipv4.ip_forward 必须为 1
防火墙 forward 链不能 DROP
内核不能因 rp_filter 丢弃 TUN 网卡返回的 TCP 包

Arch Linux 默认 ip_forward=0，UFW 默认 DEFAULT_FORWARD_POLICY="DROP"，这两个挡住转发。就算前两步都改了，在内核 6.x 上 ping 能通但 curl 超时——TCP 握手包从 TUN 网卡回来时被 rp_filter=1 丢掉。表现就是 mihomo 日志能看到 [TCP] ... using DIRECT，但连接一直 timeout。

修复

1. 开启 ip_forward

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-mihomo.conf
sudo sysctl -p /etc/sysctl.d/99-mihomo.conf

2. UFW forward 改为 ACCEPT

sudo sed -i 's/DEFAULT_FORWARD_POLICY="DROP"/DEFAULT_FORWARD_POLICY="ACCEPT"/' /etc/default/ufw
sudo ufw reload

3. 开启 auto-redirect

在 config.yaml 的 tun 部分加 auto-redirect: true：

tun:
  enable: true
  stack: system
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true

auto-redirect 会自动配置 nftables 规则重定向 TCP 连接，绕过 rp_filter 对 TUN 网卡返回包的过滤。改完重启 mihomo。

另一个选择

不想改系统转发配置的话，可以换 TUN 协议栈：

mixed：TCP 用 system 栈，UDP 用 gvisor 栈，兼容性比 system 好，性能比纯 gvisor 高
gvisor：完全在用户态处理 TCP/IP，不依赖内核转发，兼容性最强但性能略低

把 config.yaml 里 tun.stack 从 system 改成 mixed 或 gvisor 即可，不需要改系统配置。