Koala

Veil：让容器流量自动走代理

Sat, 18 Apr 2026 00:00:00 +0800

之前在服务器上跑容器，有些容器需要走代理才能联网。一开始我每个容器里都装代理客户端，配环境变量、映射端口，几台机器下来就烦了。后来一想，与其每个容器单独折腾，不如直接建一个共享的代理网络，容器加进来就自动走代理，不用改任何配置。项目开源在 github.com/therainisme/veil

怎么做到的

两个容器：veil-net 跑 Mihomo（开了 TUN 模式），veil-box 是干活的环境。关键就一行配置：

network_mode: "service:veil-net"

这让 veil-box 共享 veil-net 的网络栈，所有流量都经过 Mihomo 的 TUN 虚拟网卡，DNS 也被 Mihomo 劫持到 127.0.0.1:53 处理。容器里的程序完全不知道代理的存在，该联网联网，该解析域名解析域名。

选 TUN 主要是图省事。HTTP/SOCKS 代理得每个应用手动配，很多命令行工具还不支持；Redir 模式只能代理 TCP，DNS 查询这种 UDP 流量管不了。TUN 在内核层面截获所有流量，TCP、UDP、ICMP 全都拿下，真正意义上透明。

用法

cp veil.yml.example veil.yml
# 编辑 veil.yml，填上你的代理服务器信息
vim veil.yml

docker compose up -d
docker exec -it -u veil veil-box bash

进容器后直接 curl google.com 试试，不需要设 http_proxy，也不需要改任何应用配置。

veil.yml.example 模板已经在仓库里了，DNS 配置和分流规则都写好了，开箱即用。

两个版本

veil-box：日常开发环境，装了 git、vim、python3、build-essential 这些常用工具
veil-actions-runner：在 veil-box 基础上加了 Docker CE，用来跑需要代理的 CI/CD 流水线

对应的 compose 文件分别是 docker-compose.yml 和 docker-compose.yml.actions-runner。

修改 WSL2 的默认内存限制

Fri, 26 Dec 2025 12:00:00 +0800

最近在 WSL2 里跑一个 Go 程序，内存用到 12GB 的时候就不动了（本机内存 24GB）。命令行里啥也没有，既没报错也没 panic，就这么静悄悄地停了。

~ Run go test ./
=== RUN TestDBMetaphysicsProblem
--- PASS: TestDBMetaphysicsProblem (10.94s)
=== RUN TestDBSequentialOP
FAIL	github.com/therainisme/mlsm	182.824s

一查文档发现，WSL2 默认内存大小上限是 Windows 的一半，来源：https://learn.microsoft.com/en-us/windows/wsl/wsl-config#main-wsl-settings

配置内存限制

在用户文件夹下（路径一般是 C:\users\你的用户名）新建一个 .wslconfig 文件，写入以下内容：

[wsl2]
memory=16GB

保存后用 wsl --shutdown 重启 WSL2。接着在 WSL2 里跑一下 free 命令，即可验证配置有没有生效：

~ free
 total used free shared buff/cache available
Mem: 16381032 909836 14426152 980 1045044 15175252
Swap: 4194304 87336 4106968

配置好之后可以看到，内存变成 16GB 了，单位是字节。占大内存的 Go 程序终于能正常跑完了。

Git 多人协作开发常见问题与解决方案

Thu, 18 Dec 2025 21:00:00 +0800

多人协作开发时，Git 使用不当很容易踩坑：冲突解决不了、误删别人代码、提交历史乱成一团……这篇文章整理了团队开发中最常遇到的问题和实战解决方案。

场景一：代码冲突了怎么办？

多人同时修改同一个文件，git pull 或 git merge 时就会遇到冲突。这是团队开发中最常见的问题。

情况 1：Pull 时发生冲突

当你执行 git pull 时提示冲突：

$ git pull
Auto-merging src/utils.js
CONFLICT (content): Merge conflict in src/utils.js
Automatic merge failed; fix conflicts and then commit the result.

解决步骤：

查看冲突文件

git status

标记为 both modified 的文件就是冲突文件。

打开冲突文件，手动解决冲突

冲突部分会被标记出来：

<<<<<<< HEAD
function calculate(a, b) {
 return a + b;
}
=======
function calculate(x, y) {
 return x * y;
}
>>>>>>> origin/main

<<<<<<< HEAD 到 ======= 之间是你的本地修改
======= 到 >>>>>>> origin/main 之间是远程的修改

手动编辑，保留需要的代码，删除标记符号。

Tailscale Peer Relay 让内网穿透更加稳定！

Thu, 18 Dec 2025 14:00:00 +0800

在 Tailscale 网络中，当设备之间无法建立 P2P 直连时，一般需要依赖 DERP（Designated Encrypted Relay for Packets）服务器来中继流量。而 2025 年 10 月，Tailscale 推出了全新的 Peer Relay 功能，让内网穿透更加简单而稳定。

Peer Relay 允许你将 Tailnet 网络中的任意设备指定为中继节点，用于转发其他设备之间的加密流量。当两台设备无法直连时，Tailscale 会优先尝试使用 Peer Relay，只有在 Relay 不可用时才回退到官方 DERP 服务器。

省流：Peer Relay 就是把你自己网络中的某台机器变成专属中继站。

Peer Relay vs DERP

DERP 的特点

DERP 服务器由官方维护，拥有全球节点覆盖，可以自动选择最近的节点，使用时无需额外配置。但自建 DERP 时需要域名和 SSL 证书，国内还需要备案，配置相对复杂。自建时还需要考虑万人骑问题。

因为特殊原因，Tailscale 官方没有国内的 DERP 服务器，所以使用体验也不佳。

Peer Relay 的特点

Peer Relay 无需域名、证书和备案，免费用户也可以配置 2 个中继节点。

前提条件

在开始配置之前，请确保：(1) 所有设备运行 Tailscale 1.86 或更高版本。（2）至少有一台服务器能够被其他节点访问。

配置教程

第一步：准备公网服务器

需要一台具有公网 IP 的服务器作为中继节点。这台服务器可以是：

云服务商的 VPS（阿里云、腾讯云等）
有公网 IP 的家庭宽带设备
Full Cone NAT 环境下的设备

第二步：在中继服务器上启用 Peer Relay

在作为中继的服务器上执行以下命令：

在 Linux 上配置 Docker 代理

Thu, 18 Dec 2025 12:00:00 +0800

开发或部署时，Docker 容器镜像往往需要从海外仓库拉取，网络不佳就会卡在 docker pull。最稳妥的办法是在宿主机为 Docker Daemon 配置一个稳定的 HTTP 代理，这样所有镜像拉取都会自动走代理通道。

配置 daemon.json

sudo mkdir -p /etc/docker
sudo nano /etc/docker/daemon.json

如果文件不存在，可以先创建一个空文件再写入以下内容：

{
 "proxies": {
 "http-proxy": "http://<host>:<port>",
 "https-proxy": "http://<host>:<port>",
 "no-proxy": "localhost,127.0.0.1,::1"
 }
}

http-proxy/https-proxy：指向网络中可用的代理服务。
no-proxy：列出访问这些地址时不经过代理，避免本地容器互访走外网绕远。

保存后执行以下命令让配置立刻生效：

sudo systemctl daemon-reload
sudo systemctl restart docker

验证代理是否生效

运行 docker info | grep -i proxy，应能看到 HTTP/HTTPS Proxy 字段。

常见问题

代理变更：更新 daemon.json，重新执行上述两行 systemctl 的命令。
私有仓库不想走代理：把仓库域名加进 no-proxy。

Hugo 部署到 Vercel 只显示 index.xml

Tue, 16 Dec 2025 20:00:00 +0800

把 Hugo 博客部署到 Vercel，结果访问网站只显示 index.xml 的内容。

问题现象

部署日志里一堆警告，没有报错：

18:17:06.313 Installing Hugo version 0.58.2
18:17:24.069 Building sites … 
WARN 2025/12/16 10:17:24 found no layout file for "HTML" for "home"
WARN 2025/12/16 10:17:24 found no layout file for "HTML" for "section"
WARN 2025/12/16 10:17:24 found no layout file for "HTML" for "page"

构建统计显示：

 Pages | 6 
 Paginator pages | 0 
 Non-page files | 0 
 Static files | 2 
 Processed images | 0 
 Aliases | 0 
 Sitemaps | 1 
 Cleaned | 0 

Total in 12 ms

Static files 只有 2 个，但构建只花了 12 毫秒，一堆找不到布局文件的警告。根本就是没有正常 build 嘛，导致访问网站就只有 RSS 订阅源。

白嫖 Vercel 搭建 GitHub 加速代理

Sat, 13 Dec 2025 08:45:00 +0800

搞这个代理服务的初衷，其实很朴实：我需要一个能加速 git clone 的小工具，但又不想多掏一分钱去维护一台服务器。Vercel 的免费套餐在性能和流量上都非常慷慨，简直就是想白嫖资本家羊毛的最好选择。

我的需要部署一个轻量级服务，实现以下功能：

将所有请求转发到 https://github.com。
确保能处理大文件的 git clone 和 push，不能有限制。
访问主页 / 时，返回一段简单明了的 Usage 文本。
设置 /robots.txt 阻止搜索引擎收录。

参考了 @lideming 的 https://md.yuuza.net/s/U52dzJZWd

为什么是 TypeScript + Edge？

一开始我根本没打算用 TypeScript。作为一个熟悉后端的人，第一反应是使用 Go 语言，因为 Go 标准库里的 ReverseProxy 作为反向代理简单高效。

我迅速用 Go 实现了第一版代码并部署到了 Vercel。在小流量测试中，一切正常。

但只要一尝试 git clone 稍微大一点的仓库，Vercel 云端 Log 会报 413 Payload Too Large。

Go 的失败，是 Serverless 架构的限制

这个问题不在于 Go 代码本身，而在于它运行的环境。

Vercel 的标准 Serverless Function（Go 就运行在这个层级上）底层基于 AWS Lambda 等技术，它在处理请求时，为了安全和稳定性，会缓冲 (Buffer) 整个请求体。当你要传输一个几 MB 甚至更大的 Git 数据包时，数据会在进入你的 Go 代码之前，就被Vercel 设置的 4.5MB 限制卡着¹，然后返回 413 错误。

NixOS 春节假期折腾之旅

Mon, 10 Feb 2025 00:00:00 +0800

春节在家刷到 ryan4yin 的博客，看完觉得 NixOS 挺有意思。折腾 Linux 这么久，/etc 下的配置文件改吐了，依赖冲突也踩了不少坑。系统一升级环境就炸，Docker 也只能临时救个急。

NixOS 让人强烈欲望入坑的特点

用一份 /etc/nixos/configuration.nix 文件定义整个系统
每次系统配置更新，都会提供 Generation 防止错误配置无法回退
完全可复现的开发环境，只需要 git clone，不再需要 pacman 或 apt

可复现特性基础

NixOS 中 /nix/store 目录是只读的，这个目录存储了所有通过 Nix 包管理器安装的软件包、库文件和配置文件。每个包都有一个唯一的哈希值路径，例如 /nix/store/l9i65cfgnxgrxlghxg792146w00kafcn-rocksdb-9.8.4/。

只读设计保证了软件包不会被乱改，同一个包的不同版本可以共存，系统更新出问题了也能直接回滚。这就是 NixOS 能做到完全可复现的关键。

安装 NixOS

我们可以从 NixOS 官方下载 Minimal ISO image，在一台全新的机器上安装 NixOS。或是通过 nixos-infect 脚本，一键将非 NixOS 的系统转换成 NixOS。后者在阿里云 ECS 上测试是可用的。

非常非常 Easy 的配置文件 /etc/nixos/configuration.nix，在下面的配置中，我们指定了 root 用户的 authorizedKeys 以及密码，配置了 ssh-server，配置了 vscode-server，主机名等信息都可以通过该配置文件完成。当把下面的文件写入后，只需要运行 nixos-rebuild switch，一切都完成了。

我的服务器通过手动划分磁盘，挂载 btrfs 后，执行 nixos-install 脚本安装。更详细的安装教程可以参考这篇博客：从 0 实现全集梦中情 OS。如果对于操作没有那么熟悉，可以现在虚拟机中尝试，后续想部署到服务器上，只需要复制配置文件到服务器，执行 nixos-rebuild switch，就都一模一样了。

# Edit this configuration file to define what should be installed on
# your system. Help is available in the configuration.nix(5) man page, on
# https://search.nixos.org/options and in the NixOS manual (`nixos-help`).

{ config, lib, pkgs, ... }:

{
 imports =
 [ # Include the results of the hardware scan.
 ./hardware-configuration.nix
 # vscode server
 (fetchTarball {
 url = "https://github.com/nix-community/nixos-vscode-server/tarball/master";
 sha256 = "09j4kvsxw1d5dvnhbsgih0icbrxqv90nzf0b589rb5z6gnzwjnqf";
 })
 ];

 boot.loader.systemd-boot.enable = true;
 boot.loader.efi.canTouchEfiVariables = true;

 # Pick only one of the below networking options.
 # networking.wireless.enable = true;
 networking.networkmanager.enable = true;

 # 配置时区等机器信息
 time.timeZone = "Asia/Shanghai";
 i18n.defaultLocale = "en_US.UTF-8";
 networking.hostName = "hostname";

 nixpkgs.config.allowUnfree = true;

 # 安装的软件
 environment.systemPackages = with pkgs; [
 openssl
 wget
 curl
 nano
 tailscale
 ];
 # 设置默认编辑器
 environment.variables = {
 EDITOR = "nano";
 };

 # 配置 OpenSSH 和 Tailscale
 services.openssh.settings = {
 PermitRootLogin = "yes";
 PasswordAuthentication = true;
 };

 # 启动系统服务，类似 systemctl enable --now xxx
 services.openssh.enable=true;
 services.tailscale.enable = true;
 services.vscode-server.enable = true;

 # Root 用户的配置
 users.users.root = {
 openssh.authorizedKeys.keys = [
 "ssh-rsa AAAAB3NzaC......tTMFP5y8v8= therainisme@qq.com"
 ];
 # 这密码我随便写的
 password = "4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865";
 };

 system.stateVersion = "24.11";
}

开发环境配置（Devbox 与 Direnv）

在软件开发中，环境配置一直是令人头疼的难题。不同项目对编译器版本、依赖库、环境变量的差异化需求，常常导致"在我的机器上能运行"的经典问题。接下来将介绍基于 Devbox 和 Direnv 管理环境方案，通过两个典型 Go 项目案例，展示如何实现开发环境的精准控制。

Wed, 01 Jan 2025 00:00:00 +0800