运维123 - 网络技术
type: channel
link: https://www.sddts.cn/index.php/category/Network/
items: next-socks5：基于 Rust 的轻量级 SOCKS5 服务器实战指南
items: 使用 Linux 设备自制路由器指南
items: EVE-NG chroot 执行 qemu-system-x86_64 权限拒绝排障复盘
items: NextTrace v1.6.1 发布：新增 MTR 模式与 MTU 探测功能
items: SSH 无 Host 头问题分析与解决方案
items: JumpServer 连接 192.168.124.48 失败排障复盘
items: 小网规模超出预期：每天超过千次更新证明其生机勃勃
items: Starlink Mini 作为家庭网络故障切换方案
items: 修复 mcporter 与 n9e-mcp-server SSE 连接挂起问题
items: OpenClaw Studio 入门指南

next-socks5：基于 Rust 的轻量级 SOCKS5 服务器实战指南
type: item
date: 2026-07-03T00:33:56+00:00
description: next-socks5：基于 Rust 的轻量级 SOCKS5 服务器实战指南一、概述1. 简介A. 是什么next-socks5 是一个用 Rust 编写的轻量级、可扩展的 SOCKS5 服务器，完整实现了 RFC 1928 与 RFC 1929 协议规范。项目由 ZingerLittleBee 开源维护，采用纯 Rust 编写，无任何 C 依赖，可生成完全静态的 musl 二进制文件以及基于 scratch 的约 3.5 MB 容器镜像。项目核心特点：自研协议栈：手写 SOCKS5 协议解析，依赖足迹刻意保持精简双模式运行：TUI 终端仪表盘与适合容器的 headless 模式安全默认：默认开启出口流量过滤，防止 SSRF 与开放中继多种部署：支持一键脚本、Docker、预编译二进制、源码编译四种方式B. 为什么学传统 SOCKS5 实现（如 Dante、3proxy）存在以下痛点：老牌服务器多为 C 语言实现，依赖复杂，编译环境要求高缺乏现代运维所需的可观测性工具UDP 中继在 NAT 与容器环境下配置繁琐安全默认不足，容易因配置疏忽变成开放中继next-socks5 通过 Rust 的内存安全特性、TUI 仪表盘的实时观测能力、以及为 NAT/Docker 场景设计的 UDP 配置选项，系统性地解决了这些问题。C. 学完能做什么在自建服务器或云主机上快速部署一个安全的 SOCKS5 代理使用 TUI 仪表盘实时观测吞吐、连接数与错误统计在 NAT、Docker bridge 等复杂网络环境下正确配置 UDP 中继根据 RFC 1928 规范理解 SOCKS5 协议的工作原理2. 前置知识A. 必备技能基本的 Linux 命令行操作能力了解 TCP/UDP 协议基础熟悉代理服务器的基本概念B. 推荐知识Rust 编程基础（仅在源码编译时需要）Docker 与 docker compose 的使用防火墙配置（iptables、ufw 或 nftables）二、核心特性1. 协议支持A. SOCKS5 命令next-socks5 支持 RFC 1928 定义的核心命令：命令支持情况说明CONNECT完整支持用于 TCP 流量代理，如 HTTP、HTTPSUDP ASSOCIATE完整支持用于 UDP 流量代理，如 DNS、QUICBIND设计拒绝按设计返回回复码 0x07，出于安全考虑不开放B. 认证机制支持两种认证方式：No-Auth（0x00）：无认证，适用于受信任网络Username/Password（0x02）：用户名密码认证，符合 RFC 1929 规范认证模式下可配置多组凭证：客户端只要匹配列表中任意一组用户名密码即可通过，无需为每个用户开放独立端口。C. 地址类型支持三种 ATYP（Address Type）：0x01：IPv4 地址0x04：IPv6 地址0x03：Domain 域名（服务器端执行 DNS 解析）无论是 CONNECT 还是 UDP ASSOCIATE 目标，服务器都会执行 DNS 解析，避免客户端泄露真实 DNS 请求。D. RFC 错误码映射完整覆盖 RFC 1928 定义的回复码 0x00 至 0x08，典型映射关系：场景回复码含义成功0x00succeeded连接数超限0x02connection not allowed by ruleset网络不可达0x03network unreachable主机不可达0x04host unreachable连接被拒0x05connection refusedTTL 过期0x06TTL expired不支持的命令0x07command not supported不支持的地址类型0x08address type not supported2. 安全设计A. 出口过滤默认开启服务器默认拒绝转发到以下地址段，作为 SSRF 与开放中继的防护：回环地址（127.0.0.0/8、::1）链路本地地址（169.254.0.0/16），包括云元数据地址 169.254.169.254私有地址段（RFC 1918：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）如确实需要访问内部目标，可通过配置文件中的 egress 段放宽限制。B. 防 slowloris 攻击握手阶段（greeting + auth + request）设置了独立的超时时间（默认 10 秒），超过 handshake_ms 未完成握手的连接将被强制断开，防止慢速攻击占用连接资源。C. 连接数限制提供两个可选的并发上限配置：max_connections：全局并发上限，防止文件描述符耗尽max_per_ip：单 IP 并发上限，防止单客户端独占资源或暴力破解两个限…

使用 Linux 设备自制路由器指南
type: item
date: 2026-03-31T06:20:12+00:00
description: 使用 Linux 设备自制路由器指南一、概述1. 简介A. 是什么本文介绍如何使用任意 Linux 设备（如迷你 PC、旧笔记本、单板计算机等）搭建功能完整的家用路由器。通过配置网络接口、防火墙、DHCP 和 DNS 服务，将一台普通计算机转变为具有路由、NAT、无线接入等功能的网络设备。B. 为什么要学硬件自由：不受商业路由器限制，可使用任意闲置设备功能可控：完全掌握网络配置，可按需定制功能安全透明：基于开源软件，避免固件后门风险教育价值：深入理解网络原理和 Linux 系统管理C. 学完能做什么使用旧电脑或迷你 PC 搭建家用路由器配置有线网络桥接和无线接入点设置 DHCP、DNS 服务和防火墙规则通过串口进行远程管理2. 前置知识A. 必备技能基本 Linux 命令操作网络基础知识（IP 地址、子网掩码、网关）文本编辑器使用（vim 或 nano）B. 推荐知识Debian Linux 基础网络接口配置经验二、硬件选择1. 设备要求A. 核心需求处理器：任意 x86 或 ARM 架构处理器（老旧 CPU 即可）内存：最低 512MB，推荐 1GB 以上网络接口：至少 2 个以太网接口（可通过 USB 扩展）存储：8GB 以上存储空间（mSATA 或 SSD）B. 推荐硬件设备类型优点缺点迷你 PC（被动散热）静音、稳定、体积小成本稍高旧笔记本屏幕键盘齐全体积大、功耗高树莓派等 SBC功耗极低性能有限台式机/服务器性能强大噪音、功耗高2. 网络接口配置A. 接口规划接口名称网络角色说明eth0WAN连接 ISP 或上级路由器eth1LAN（有线）连接交换机或直连设备wlan0LAN（无线）提供 Wi-Fi 接入B. 接口扩展USB 网卡：可通过 USB 网卡扩展网络接口性能考虑：USB 网卡稳定性不如板载接口多接口：可接入多个 USB 网卡并桥接三、系统架构1. 网络拓扑graph TB ISP[ISP/WAN] -->|eth0| Linux[Linux 路由器] Linux -->|br0 桥接| Switch[有线 LAN] Linux -->|wlan0| WiFi[无线 AP] Switch --> Client1[PC1] Switch --> Client2[PC2] WiFi --> Mobile[移动设备] Linux -->|dnsmasq| DNS[DNS/DHCP 服务] Linux -->|nftables| FW[防火墙/NAT]2. 系统组成A. 核心组件Debian Linux：基础操作系统hostapd：无线接入点服务dnsmasq：DNS 和 DHCP 服务器bridge-utils：网络桥接工具nftables：防火墙和 NATB. 数据流向流量进入：从 WAN（eth0）接收外部网络数据流量转发：通过内核 IP 转发功能在接口间传递NAT 处理：使用 nftables 进行地址转换流量输出：向 LAN（br0）分发内部网络数据四、系统安装1. Debian 安装配置A. 安装前准备禁用 PXE 网络启动：BIOS/UEFI 设置中关闭 PXE Boot 选项设置电源管理：设置最低时钟速度以降低功耗禁用 USB 或 PCI 设备的电源管理启用断电恢复自动开机功能显示处理：部分设备需要连接显示器才能正常启动可插入 HDMI 假负载欺骗系统B. 安装非自由固件启用 non-free-firmware 仓库以支持更多硬件：Intel 无线网卡：sudo apt install firmware-iwlwifiRealtek 无线网卡：sudo apt install firmware-ath9k-htcAtheros 老旧网卡：sudo apt install firmware-atheros2. 安装核心软件包sudo apt install bridge-utils hostapd dnsmasq安装完成后系统约包含 250 个软件包。五、网络配置1. 持久化接口命名现代 Linux 使用基于物理位置的接口命名（如 enp0s31f6），为便于管理，可重命名为传统格式（ethX）。为每个接口创建配置文件：/etc/systemd/network/10-persistent-ethX.link[Match] MACAddress=AA:BB:CC:DD:00:11 [Link] Name=ethX替换 MACAddress 为实际网卡 MAC 地址，Name 为 desired 接口名称。2. 无线网络配置创建无线接入点配置文件：/etc/hostapd/hostapd.confinterface=wlan0 bridge=br0 hw_mode=g channel=11 ieee8021…

EVE-NG chroot 执行 qemu-system-x86_64 权限拒绝排障复盘
type: item
date: 2026-03-23T08:11:14+00:00
description: EVE-NG chroot 执行 qemu-system-x86_64 权限拒绝排障复盘一、事件概述1. 事件背景在 EVE-NG 实验环境中，节点启动阶段执行 chroot . /opt/qemu-2.12.0/bin/qemu-system-x86_64 失败，报错为 Permission denied，导致实验节点无法正常拉起。2. 影响范围A. 影响对象受影响对象为当前实验实例目录 /opt/unetlab/tmp/0/2b55d7be-2cb0-4b0b-aa69-68597d7dc51e 下的节点。B. 影响时长从故障暴露到完成修复约数分钟。C. 影响功能QEMU 进程无法在 chroot 环境中启动，节点启动流程中断。3. 严重程度P2，单实验实例节点启动失败，不影响宿主机基础服务。二、事件时间线1. 故障发生（16:00）A. 现象描述执行 chroot . /opt/qemu-2.12.0/bin/qemu-system-x86_64 返回 Permission denied。B. 初步判断优先怀疑二进制无执行位、挂载 noexec、chroot 目录权限异常。2. 问题定位（16:02）A. 关键检查完成以下检查：qemu-system-x86_64 文件权限正常，为 -rwxr-xr-x。挂载参数未发现 noexec。直接在宿主机路径执行 qemu-system-x86_64 --version 正常。仅在 chroot 内执行失败。B. 进一步验证检查 ELF 解释器路径为 /lib64/ld-linux-x86-64.so.2，并确认 chroot 内对应文件存在，但权限为 -rw-r--r--，缺少执行位。3. 修复实施（16:05）A. 处理措施发现 /opt/unetlab/tmp/.../jail 为只读 bind 挂载，不能直接在 tmp 路径改权限。 转而在源目录 /opt/unetlab/jail/lib64/ld-linux-x86-64.so.2 执行 chmod 755。B. 验证结果再次执行 chroot /opt/unetlab/tmp/.../2 /opt/qemu-2.12.0/bin/qemu-system-x86_64 --version 成功输出 QEMU 版本信息。sequenceDiagram participant U as 运维 participant H as 宿主机 participant C as chroot 环境 U->>H: 执行 qemu-system-x86_64 --version H-->>U: 正常 U->>C: chroot 执行 qemu-system-x86_64 C-->>U: Permission denied U->>H: 检查 ld-linux-x86-64.so.2 权限 H-->>U: 发现无执行位 U->>H: 修复 /opt/unetlab/jail/lib64 权限 U->>C: chroot 再次执行 C-->>U: 执行成功三、问题分析1. 直接原因chroot 环境依赖的动态加载器 /lib64/ld-linux-x86-64.so.2 缺少执行权限，导致动态链接 ELF 程序在 chroot 内无法启动。2. 根本原因（5 Whys）A. 为什么 qemu 无法在 chroot 内运行因为动态加载器不可执行，内核无法完成程序加载。B. 为什么只在 chroot 内失败宿主机执行使用宿主机 /lib64；chroot 执行使用 jail 内 /lib64，二者权限状态不同。C. 为什么在 tmp 路径修复失败tmp 下 jail 是只读 bind 挂载点，权限变更需要在源目录 /opt/unetlab/jail 进行。3. 深层反思排障初期若只盯着 qemu 二进制本身，容易漏掉动态加载器权限和 mount 绑定关系这两个关键点。四、解决方案1. 临时方案A. 实施措施在源目录修复动态加载器权限：chmod 755 /opt/unetlab/jail/lib64/ld-linux-x86-64.so.2。B. 效果评估当前实例节点可恢复启动，问题立即解除。2. 永久方案A. 改进措施将以下检查加入 EVE-NG 运维巡检：检查 /opt/unetlab/jail/lib64/ld-linux-x86-64.so.2 是否为 -rwxr-xr-x。检查 /opt/unetlab/tmp 下 jail 与 qemu 目录挂载关系是否符合预期。节点启动失败时优先执行 chroot + --version 快速自检。B. 实施计划在后续运维文档中补充该排障条目，并形成标准化故障检查清单。3. 预防措施对 /opt/u…

NextTrace v1.6.1 发布：新增 MTR 模式与 MTU 探测功能
type: item
date: 2026-03-22T13:58:10+00:00
description: NextTrace v1.6.1 发布：新增 MTR 模式与 MTU 探测功能一、新闻概述1. 标题NextTrace v1.6.1 发布：新增 MTR 模式与 MTU 探测功能2. 发布时间2026 年 3 月 21 日3. 来源GitHub Release - nxtrace/NTrace-core二、核心内容1. 事件摘要A. 主要内容NextTrace 是一个开源的网络路由追踪工具，此次 v1.6.1 版本更新带来了重大功能增强，包括新增 MTR 模式、独立的 MTU 探测模式，以及 Windows 平台依赖重构。B. 核心亮点新增完整的 MTR 模式，支持交互式 TUI、报告模式和流式输出独立的 MTU 路径探测功能同一版本提供三种构建变体：完整版、精简版、MTR 专用版Windows 平台移除 Npcap 依赖，改用 WinDivert2. 关键信息A. 版本号v1.6.1B. 重要数据GitHub Star：7.7kFork 数：461支持平台数：101 个构建包覆盖架构：amd64、arm64、386、armv5/v6/v7、mips、ppc64、riscv64、s390x、loong64 等C. 涉及产品NextTrace 网络路由追踪工具3. 背景介绍A. 前置版本v1.5.0 是上一个主要版本，引入了多项功能改进。B. 相关上下文NextTrace 是一个用 Go 语言编写的开源路由追踪工具，支持多种探测协议（ICMP、TCP、UDP），并提供 GeoIP 定位、RDNS 反解等增强功能。三、详细报道1. 主要内容A. 功能更新新增 MTR 模式支持交互式 TUI 界面提供 --report 报告模式支持 --raw 流式输出新增 --wide、--show-ips、-y/--ipinfo 等显示控制选项重写 MTR 调度与统计逻辑改为 Per-Hop 独立调度支持每跳多并发探测修复高丢包场景下的统计偏差问题修复 ghost row、超发残影和已到达目的地后高 TTL 脏数据问题新增独立 MTU 探测模式使用 --mtu 参数启动独立于普通 traceroute/MTR支持单独的输出格式与 JSON schema兼容 GeoIP、RDNS、--dot-server 等常用参数B. 技术改进Windows 平台重构移除对 Npcap 的依赖ICMP/TCP/UDP 监听统一改为 WinDivert SNIFF 模式修复上下文取消后句柄未释放导致的卡住问题探测包大小语义调整--psize 现在表示探测包总大小（包含 IP 与探测协议头）默认按协议和 IP 族自动取最小合法值支持负值随机化每个 probe 的包大小新增 -Q/--tos 用于设置 IP TOS/traffic class输出文件能力常规 traceroute 支持 --output <FILE>支持 --output-default 便于实时落盘和脚本处理DoT 服务器增强--dot-server 现在影响目标域名解析、GeoIP、LeoMoe FastIP 等相关请求失败时自动回退到系统 DNSC. 兼容性说明TTY 下支持状态与 PMTU 高亮重定向或管道输出退化为无 ANSI 的逐行流式文本补齐 Windows 下的 MTU 处理问题WinDivert 超时、过滤与权限提示改进2. 技术细节A. 版本架构graph TB subgraph Versions[NextTrace v1.6.1 三种构建版本] A[nexttrace 完整版] B[nexttrace-tiny 精简版] C[ntr MTR专用版] end subgraph Features[功能对比] F1[常规 traceroute] F2[MTR TUI] F3[MTR 报告模式] F4[Globalping] F5[WebUI] F6[快速跟踪] F7[MTU 探测] end A --> F1 A --> F2 A --> F3 A --> F4 A --> F5 A --> F6 A --> F7 B --> F1 B --> F6 B --> F7 C --> F2 C --> F3 style A fill:#e1f5ff style B fill:#fff4e1 style C fill:#ffe1f5B. 功能架构graph TD A[用户命令] --> B[常规 traceroute] A --> C[MTR 模式] A --> D[MTU 探测] B --> E[GeoIP 定位] B --> F[RDNS 反解] C --> E C --> F D --> F style B fill:#4CAF50 style C fill:#2196F3 style…

SSH 无 Host 头问题分析与解决方案
type: item
date: 2026-03-19T00:12:20+00:00
description: SSH 无 Host 头问题分析与解决方案一、事件概述1. 事件背景exe.dev 是一个提供虚拟机服务的平台，为每个虚拟机提供标准的 URL，同时支持 HTTPS 和 SSH 访问。用户可以直接使用域名连接虚拟机，就像在浏览器中访问网站一样简单。2. 问题陈述exe.dev 采用固定费率订阅模式，为用户提供大量虚拟机。然而，为每台虚拟机分配独立的 IPv4 地址会导致订阅成本大幅上升。同时，仅使用 IPv6 意味着部分用户无法通过 Web 访问虚拟机。因此，exe.dev 需要在多个虚拟机之间共享 IPv4 地址。对于 Web 访问，这是一个长期存在的解决方案，但 SSH 协议没有 Host header，无法通过域名区分不同的虚拟机。3. 影响范围所有需要通过 SSH 访问的虚拟机共享 IPv4 地址的场景需要统一域名行为的服务二、问题分析1. Web 服务的解决方案Web 服务早已解决了同一 IP 承载多个域名的问题。Web 浏览器在 HTTP 请求中发送访问域名作为 Host header。服务器可以根据这个 header 将请求路由到正确的虚拟机。graph LR C[客户端] --> P[代理服务器] P -->|Host: vm1.example.com| V1[虚拟机1] P -->|Host: vm2.example.com| V2[虚拟机2] P -->|Host: vm3.example.com| V3[虚拟机3]2. SSH 协议的限制SSH 协议没有等效于 Host header 的机制。当客户端发起 SSH 连接时，服务器只能看到连接来源的 IP 地址和端口，无法知道客户端使用的是哪个域名。这意味着如果多个虚拟机共享同一个 IPv4 地址，SSH 代理无法将连接路由到正确的虚拟机。3. 根本原因SSH 协议设计之初并未考虑域名虚拟化的需求。它是基于网络层传输的协议，只关注 IP 地址和端口，不关心应用层的域名信息。三、解决方案1. SSH IP Sharing 架构exe.dev 采用了一种创新的解决方案：不使用单一 IP 地址承载所有虚拟机，而是维护一个公网 IPv4 地址池。每个虚拟机被分配一个相对于其所有者唯一的地址。2. DNS 配置方式传统方式使用 A 记录直接指向 IP 地址，而 exe.dev 使用 CNAME 记录指向子域名：$ dig undefined-behavior.exe.xyz ; <<>> DiG 9.10.6 <<>> undefined-behavior.exe.xyz ... ;; ANSWER SECTION: undefined-behavior.exe.xyz. 230 IN CNAME s003.exe.xyz. s003.exe.xyz. 230 IN A 16.145.102.7CNAME 记录 s003.exe.xyz 代表一个特定的 IPv4 地址池。虽然这个 IP 地址被多个虚拟机使用，但对于某个特定用户来说，它只被该用户的一台虚拟机使用。3. 路由机制SSH 代理使用以下信息来路由连接：公钥：识别用户身份IP 地址：识别连接来源{用户, IP} 元组唯一标识用户正在连接的虚拟机。sequenceDiagram participant C as SSH 客户端 participant DNS as DNS 服务器 participant P as SSH 代理 participant V as 目标虚拟机 C->>DNS: 查询 vm.exe.xyz DNS-->>C: 返回 CNAME s003.exe.xyz DNS-->>C: 返回 A 记录 16.145.102.7 C->>P: SSH 连接到 16.145.102.7 P->>P: 获取连接来源 IP C->>P: 发送公钥 P->>P: 根据 {公钥, IP} 元组查找虚拟机 P->>V: 转发连接 V-->>C: SSH 会话建立4. 系统实现要点A. IP 分配策略创建虚拟机时，根据拥有虚拟机的用户（或未来的团队）仔细分配 IP 地址。这要求跨系统的通信和协调。B. 连接来源 IP 获取SSH 代理需要能够确定请求进入的本地 IP 地址。在裸金属环境中这很容易，但在云环境中，公网 IP 通过 NAT 转换为私有 VPC 地址，实现起来更复杂。C. 管理软件所有这些都需要定制的管理软件，因此 exe.dev 不建议将其作为一般解决方案推荐给希望将虚拟机 SSH 访问复用到单个 IP 的人。四、技术细节1. 元组查找机制SSH 代理维护一个查找表，键是 {用户, IP} 元组，值是对应的虚拟机。当 SSH 连接到达时：代理记录连接进入的 IP 地址读取客户端发送的公钥，识别用户身份使…

JumpServer 连接 192.168.124.48 失败排障复盘
type: item
date: 2026-03-18T07:23:30+00:00
description: JumpServer 连接 192.168.124.48 失败排障复盘一、事件概述1. 事件背景在同一网络环境中，本地与 192.168.124.210 宿主机均可直接 SSH 登录 192.168.124.48，但通过 JumpServer 页面连接同一资产失败，表现为连接超时。2. 影响范围A. 影响对象通过 JumpServer 访问 192.168.124.48 的运维会话。B. 未受影响对象直接从本地或 192.168.124.210 宿主机执行 SSH 到 192.168.124.48。C. 业务影响堡垒机路径不可用，导致统一审计入口受阻，但不影响目标主机自身 SSH 服务可用性。3. 严重程度中等。属于单资产访问异常，但影响堡垒机标准运维路径。二、现象与证据链1. 关键现象A. 主机对比测试192.168.124.210 宿主机到 192.168.124.48:22 可达。JumpServer 的 koko 容器到 192.168.124.48:22 超时。koko 容器到 192.168.124.196:22 正常。B. 抓包结论在 192.168.124.48 抓包可见两类来自 192.168.124.210 的 TCP SYN：一类可得到 SYN-ACK，并完成短连接握手。另一类持续重传 SYN，无任何 SYN-ACK 返回。说明问题并非简单的目标端口关闭，也非全网段 ACL 阻断，而是同源 IP 下不同连接特征被内核策略选择性丢弃。2. 拓扑与路径graph LR U[运维用户] --> J[JumpServer Web] J --> K[koko 容器 192.168.250.7] K --> N[宿主机 NAT 源地址转为 192.168.124.210] N --> T[目标主机 192.168.124.48:22] H[宿主机 192.168.124.210 直接 SSH] --> T三、根因分析1. 直接根因192.168.124.48 开启了已废弃且高风险的内核参数：net.ipv4.tcp_tw_recycle = 1该参数在 NAT 场景下会根据时间戳特征对同源地址连接做严格回收与校验，容易误判并丢弃合法 SYN。2. 为什么只影响 JumpServer 路径A. 共同点两条路径在目标主机侧看到的源地址都可能是 192.168.124.210。B. 差异点JumpServer 通过容器与 NAT 转发，连接时间戳与会话模式和宿主机直连不同，触发 tcp_tw_recycle 的误杀条件，导致 48 不回 SYN-ACK。C. 对照验证关闭 tcp_tw_recycle 后，koko 到 192.168.124.48:22 立即恢复连通，且 SSH 握手可进入认证阶段。四、修复动作1. 立即修复在 192.168.124.48 执行：sysctl -w net.ipv4.tcp_tw_recycle=02. 持久化修复新增文件 /etc/sysctl.d/99-disable-tcp-tw-recycle.conf：net.ipv4.tcp_tw_recycle = 0加载配置：sysctl -p /etc/sysctl.d/99-disable-tcp-tw-recycle.conf3. 修复后验证docker exec jms_koko nc -vz -w 3 -n 192.168.124.48 22 返回 succeeded。docker exec jms_koko ssh 到 192.168.124.48 已能完成握手并进入认证阶段。五、预防与标准化建议1. 内核参数基线在所有仍运行老内核的主机上禁用 tcp_tw_recycle。建议保留 tcp_tw_reuse 的审慎配置，避免误用高风险参数。2. 变更前检查清单涉及 SSH 异常时，必须做三点对照：宿主机直连、容器路径、目标机抓包。同时采集目标机 sysctl 网络参数，优先排查历史兼容性开关。3. 架构层建议明确 JumpServer 的真实出网路径与源地址模型。对关键资产建立堡垒机链路自动探测，提前发现单点异常。六、结论本次故障并非 JumpServer 平台整体不可达，也非 192.168.124.0/24 网段通断问题，而是目标主机 192.168.124.48 的遗留内核参数 tcp_tw_recycle 在 NAT 场景下触发误杀。参数关闭后，JumpServer 到该资产连接恢复正常。参考资料Linux tcp_tw_recycle 在 NAT 场景的已知问题说明

小网规模超出预期：每天超过千次更新证明其生机勃勃
type: item
date: 2026-03-17T11:27:46+00:00
description: 小网规模超出预期：每天超过千次更新证明其生机勃勃一、新闻概述1. 标题小网规模超出预期：每天超过千次更新证明其生机勃勃2. 发布时间2026 年 3 月 16 日3. 来源Kevin Boone 个人博客二、核心内容1. 事件摘要A. 主要内容Kevin Boone 通过对 Kagi 搜索引擎小网列表的分析，发现"小网"（small web）的规模和活跃度远超预期，每日更新量超过 1200 次，证明私人网站社区依然充满活力。B. 核心亮点小网列表从约 6000 个站点增长至 32000 个有效活跃站点约 9000 个单日更新量超过 1200 次小网规模太大，无法像 Gemini 协议那样实现全量聚合2. 关键信息A. 涉及技术普通网络浏览器和服务器Gemini 协议RSS/ATOM feed 聚合Kagi 搜索引擎小网列表B. 重要数据小网站点总数：约 32000 个可索引站点：约 25000 个每月至少更新一次的站点：约 9000 个单日更新量：1251 次（以 2026 年 3 月 15 日为例）C. 研究方法编写程序下载每个 feed，检查时间戳以确定更新频率3. 背景介绍A. 什么是小网使用普通网络浏览器和服务器、用于私人网站、无广告和商业追踪的互联网空间。B. Gemini 协议对比Gemini 协议：约 6000 个站点（capsules），约 100 名活跃用户小网：规模远超 Gemini，生态更加活跃三、详细报道1. 研究动机作者在使用 Gemini feed 聚合器时产生了启发。由于 Gemini 社区规模较小，可以将所有站点的更新聚合到单个页面，方便用户浏览新内容。作者想知道是否可以为整个小网实现类似的功能。2. 研究过程graph LR A[研究动机] --> B[获取站点列表] B --> C[Kagi 小网列表] C --> D[下载所有 feeds] D --> E[过滤无效站点] E --> F[过滤低频更新站点] F --> G[统计每日更新量] G --> H[分析可行性]A. 数据来源Kagi 搜索引擎的小网列表，包含用户提名的站点。入选标准包括站点规模较小，并且发布更新 feed。B. 数据处理流程下载每个站点的 feed检查时间戳确定更新频率排除无时间戳的站点排除无法访问或 feed 无效的站点排除每月更新少于一次的站点3. 研究结果A. 规模数据初始列表：约 32000 个站点可索引站点：约 25000 个（排除无效和无法访问的站点）活跃站点：约 9000 个（每月至少更新一次）B. 活跃度数据2026 年 3 月 15 日当天有 1251 次更新。早期日期的数据也基本持平。C. 更新质量这些更新不仅仅是拼写修正，而是向网站添加新内容。4. 技术细节A. Feed 聚合原理Feed 聚合器是检查一系列站点或 capsule 的 feeds，并按时间顺序发布更新的服务。Feed 通常采用 ATOM 或 RSS 格式，即 XML 文档。B. 可行性分析小网虽然名为"小"网，但规模和活跃度已超过预期。每日超过 1200 次更新的数量意味着：可以发布所有更新，但无人有足够时间全部阅读无法像 Gemini 那样实现单页面全量聚合需要更加精细的分类和筛选机制graph TB subgraph Gemini 协议 G1[约 6000 个站点] G2[约 100 名活跃用户] G3[可实现单页聚合] end subgraph 小网 W1[约 32000 个站点] W2[约 9000 个活跃站点] W3[每日 1200+ 次更新] W4[无法单页全量聚合] end四、影响分析1. 行业影响A. 技术趋势在互联网被广告和商业追踪主导的时代，小网证明了私人、非商业化网站仍有生存空间。这反映了用户对去中心化、个人化表达方式的需求。B. 生态繁荣从 6000 到 32000 个站点的增长，表明小网正在快速发展。2. 用户影响A. 信息获取挑战单日更新量超过 1200 次，意味着用户需要更加智能的内容发现机制，而非简单的全量聚合。B. 参与门槛降低只要有基本的网络浏览器和服务器，任何人都可以参与小网，无需复杂的协议或专用软件。3. 概念澄清"小"网的定义从来不是基于站点数量，而是缺乏商业影响。这一点很重要，因为即便规模扩大，小网依然保持了其核心理念。五、各方反应1. 作者观点作者认为这是一个好消息，表明小网非常活跃且正在增长。这也是一个坏消息，因为无法实现类似 Gemini 的简单聚合器。2. 社区意义尽管聚合全量更新不现实，但小网的规模和活跃度是值得庆祝的。这说明在大型科技平台主导的互联网时代，个人网站仍有重要地位。六、相关技术1. Gemini 协议一种完全不同于常规网络的协议和软件，功能受限以至于几乎无法被…

Starlink Mini 作为家庭网络故障切换方案
type: item
date: 2026-03-16T23:25:52+00:00
description: Starlink Mini 作为家庭网络故障切换方案一、概述1. 简介A. 是什么Starlink Mini 是 SpaceX 推出的紧凑型卫星互联网设备，可作为家庭网络的备用连接方案。当主网络（如 FTTP 光纤连接）出现故障时，自动切换到卫星网络，确保网络不间断。B. 为什么需要网络可靠性：避免单一网络连接故障导致的断网应急场景：应对网络运营商线路故障、光缆损坏等情况技术探索：体验卫星互联网技术，作为技术爱好者的备用方案C. 应用场景家庭网络冗余设计离网环境（如停电、基础设施故障）下的网络接入移动办公和远程工作的备用连接2. 前置知识A. 必备技能基础网络配置知识（IP 地址、路由、DNS）UniFi 网络设备配置经验IPv6 基本概念B. 推荐知识网络故障切换（Failover）原理DHCPv6 和 SLAAC 协议二、Starlink Mini 介绍1. 硬件规格A. 产品特点紧凑型设计，便携性好功耗约 13W（软件更新后）需要相对开阔的视野，但可透过玻璃薄层工作自适应天线技术，部分遮挡仍可用B. 硬件成本设备价格：159 英镑，相比具备类似能力的 4G/5G 备用方案更经济。C. 优势几乎可在任何有天空视野的地方工作不依赖移动网络覆盖可放置于待机模式，按需激活2. 资费方案A. 待机计划（Standby Plan）月费：4.50 英镑B. 计划特点可随时重启完整带宽服务待机期间提供无限低速数据（500kbps），足够支持 Google Meet、FaceTime、Claude 等应用比大多数作为备用的移动数据套餐更便宜C. 资费变化2025 年 8 月，Starlink 将免费的"暂停模式"替换为付费的"待机模式"。三、网络性能观察1. 延迟表现最佳延迟：18ms（ping 1.1.1.1）峰值延迟：65ms平均延迟：26ms对比：主 FTTP 连接的最佳延迟约为 5ms。2. 功耗表现平均功耗：约 13W（软件更新后）适合由太阳能电池供电的场景3. 其他观察UniFi 新增了查看遮挡情况和天线延迟的仪表盘功能Starlink 推出了 100Mbps、200Mbps 和 Max（400Mbps+）速度档位订阅 Residential Max 计划可免费获得 Starlink Mini配置极其简单：插电、朝向天空、等待 5-10 分钟四、IPv6 配置详解1. 背景A. Starlink IPv6 支持Starlink 原生支持 IPv6，通过 DHCPv6 Prefix Delegation 分配 /56 前缀。B. CGNAT 问题Starlink 在 IPv4 上使用运营商级 NAT（CGNAT），导致端口转发不可用。IPv6 可解决此问题，提供可路由的公网地址空间。C. UniFi 兼容性问题UniFi 存在一个 bug，导致 IPv6 默认路由无法自动分配，需要手动修复。2. 初始配置A. 基本步骤导航到 WAN 设置（Settings → Internet → Primary WAN）将 Advanced 设置为 Manual启用 IPv6将 IPv6 Connection 设置为 SLAAC（关键：必须使用 SLAAC，而非 DHCPv6）取消勾选 Prefix Delegation 的 Auto将 Prefix Delegation Size 设置为 56B. LAN 配置应用设置后，在 Internet 字段中应看到 IPv6 地址。在 LAN 网络上使用 SLAAC 启用 IPv6 地址分配。3. UniFi IPv6 路由 Bug 修复A. 问题确认此时你可能认为一切正常，但从 LAN 客户端访问 IPv6 资源时会发现无法正确路由。这是因为 UniFi 的 bug 导致。B. 修复步骤步骤 1：SSH 登录 UniFi 设备若需先设置 SSH 密钥，前往 Control Plane → Console → SSH 进行配置。用户名为 root，密码为控制台设置中设置的密码。步骤 2：检查默认路由是否缺失ip -6 route show default可能返回空白，确认问题存在。步骤 3：等待路由器通告运行 tcpdump 捕获来自 Starlink 的路由器通告（RA）：tcpdump -i eth7 -vvv icmp6等待 RA（Router Advertisement）数据包。它看起来像这样：10:51:39.297010 IP6 fe80::200:6edd:3e00:101 > ff02::1: ICMP6, router advertisement, length 104重要部分是开头的 IPv6 链路本地地址（示例中为 fe80::200:6edd:3e00:101）。这就是你的默…

修复 mcporter 与 n9e-mcp-server SSE 连接挂起问题
type: item
date: 2026-03-02T06:29:19+00:00
description: 修复 mcporter 与 n9e-mcp-server SSE 连接挂起问题一、事件概述1. 事件背景用户在使用 mcporter 调用 Nightingale MCP 工具时，程序出现挂起现象。mcporter list 显示 nightingale 服务为 offline 状态，执行 mcporter call nightingale.list_active_alerts 命令时程序无响应。2. 影响范围A. 影响功能Nightingale MCP 工具调用全部失败无法通过 MCP 协议访问 Nightingale 监控数据影响 list_active_alerts、list_history_alerts 等所有监控工具B. 影响时长调试过程持续约 2 小时，涉及多次代码修改和验证3. 严重程度P2 级问题，影响特定 MCP 服务器的可用性二、事件时间线1. 问题发现（初始阶段）A. 现象描述执行 mcporter list 时，nightingale 显示为 "offline — unable to reach server"B. 初步判断根据计划文件，问题根源是配置不匹配：mcporter 配置使用 stdio 模式，但 n9e-mcp-server 已切换到 HTTP SSE 模式运行。2. 配置调整（第一阶段）A. 处理措施修改 /home/jacky/.claude/config/mcporter.json，将 nightingale 从 stdio 模式改为 HTTP SSE 模式B. 效果评估问题未解决，mcporter list 仍显示 nightingale 为 offline3. 用户关键反馈（第二阶段）A. 发现途径用户注意到服务器日志中 session_id 为空字符串：session_id=""B. 用户提问"from the log i see session_id is null, shall this is the problem?"4. SessionID 调查（第三阶段）A. 调研方法通过 zread 工具检查 go-sdk 源代码 mcp/sse.goB. 关键发现在 sseServerConn 和 sseClientConn 的 SessionID 方法中发现以下注释：// TODO(jba): get the session ID. (Not urgent because SSE transports have been removed from the spec.) func (s *sseServerConn) SessionID() string { return "" }C. 结论空的 session_id 是预期行为，SSE 传输已从 MCP 规范中移除，不是问题根源5. 真实问题定位（第四阶段）A. 处理措施使用 curl 直接测试 SSE 端点，验证服务器是否正常响应B. 关键发现curl 测试成功，SSE 流程正常工作。问题在于 mcporter 的传输模式回退逻辑：尝试 Streamable HTTP 模式：失败，提示 "sessionid must be provided"回退到 SSE 模式：挂起6. 配置文件定位（第五阶段）A. 处理措施搜索并确认 mcporter 的实际配置文件位置B. 关键发现mcporter 使用 /home/jacky/.mcporter/mcporter.json，而非 /home/jacky/.claude/config/mcporter.jsonC. 修复措施更新正确的配置文件，将 URL 从远程地址改为本地地址7. Token 认证逻辑修复（第六阶段）A. 问题分析检查 n9e-mcp-server 的 HTTP 处理代码，发现所有请求（包括 POST 到 session endpoint）都强制要求 token 认证B. 问题根因POST 请求到 /mcp?sessionid=XXX 时，这些请求应仅使用 sessionid 认证，不应再次验证 tokenC. 修复措施修改 /mydata/code/mcp/n9e-mcp-server/internal/http_server.go，添加条件判断：mainHandler.HandleFunc("/mcp", func(w http.ResponseWriter, r *http.Request) { // POST 请求带 sessionid 直接转发到 SSE handler if r.Method == http.MethodPost && r.URL.Query().Get("sessionid") != "" { sseHandler.ServeHTTP(w, …

OpenClaw Studio 入门指南
type: item
date: 2026-03-01T10:57:36+00:00
description: OpenClaw Studio 入门指南一、概述1. 简介A. 是什么OpenClaw Studio 是一个简洁的 Web 仪表板，用于管理和控制 OpenClaw Gateway。它提供统一的界面来连接 Gateway、查看和创建 agents、进行对话、管理审批任务以及配置定时作业。B. 为什么学提供可视化界面，简化 OpenClaw 的操作流程支持多种部署场景，满足本地和云端需求集中管理 agents、聊天、审批和作业配置C. 学完能做什么在本地或云端部署 OpenClaw Studio配置 Studio 与 Gateway 的连接使用 Studio 界面管理 agents 和执行任务二、环境准备1. 系统要求Node.js 18+（推荐使用 LTS 版本）OpenClaw Gateway URL 和访问 tokenTailscale（可选，推荐用于远程访问）2. 安装步骤推荐安装方式（npx）npx -y openclaw-studio@latest从源码安装（高级用户）git clone https://github.com/grp06/openclaw-studio.git cd openclaw-studio npm install npm run dev3. 验证安装安装完成后，在浏览器中打开 http://localhost:3000，确认 Studio 界面正常加载。三、核心概念1. 基本术语Gateway：OpenClaw 的核心服务，负责 agents 的执行和管理Studio：Web 仪表板，提供图形化界面与 Gateway 交互Upstream：Studio 连接到 Gateway 的上游服务Agent：可执行特定任务的智能代理Tailscale：虚拟网络服务，用于安全的远程访问2. 工作原理OpenClaw Studio 采用双路径网络架构，Studio 作为中间层连接浏览器和 Gateway。graph LR subgraph 用户终端 Browser[浏览器] end subgraph Studio主机 Studio[OpenClaw Studio Web服务] WS1[WebSocket 3000端口] end subgraph Gateway主机 Gateway[OpenClaw Gateway] WS2[WebSocket 18789端口] end Browser -->|HTTP/UI| Studio Browser <-->|WebSocket 实时更新| WS1 WS1 -->|WebSocket| WS2 WS2 <--> Gateway网络连接说明：浏览器到 Studio：HTTP 用于 UI 界面，WebSocket 用于实时更新Studio 到 Gateway：Studio 服务器通过 WebSocket 连接配置的上游 URL3. 部署模式Studio 支持三种常见的部署场景，根据 Gateway 和 Studio 的运行位置选择合适的方式。四、快速上手1. 场景选择根据你的网络环境选择部署场景：场景 A：Gateway 本地运行，Studio 本地运行（同一台计算机）场景 B：Gateway 云端运行，Studio 本地运行（你的笔记本电脑）场景 C：Studio 云端运行，Gateway 云端运行（始终在线）2. 场景 A：Gateway 本地，Studio 本地适用于开发和测试环境，两者在同一台计算机上运行。安装和启动npx -y openclaw-studio@latest cd openclaw-studio npm run dev配置连接打开 http://localhost:3000，在 Studio 中设置：Upstream URL: ws://localhost:18789Upstream Token: 你的 Gateway token（可通过 openclaw config get gateway.auth.token 获取）3. 场景 B：Gateway 云端，Studio 本地适用于 Gateway 部署在云服务器，而在本地进行管理的场景。运行 Studionpx -y openclaw-studio@latest cd openclaw-studio npm run dev配置网络连接方案一：Tailscale Serve（推荐）在 Gateway 主机上：tailscale serve --yes --bg --https 443 http://127.0.0.1:18789在 Studio（你的笔记本）中：Upstream URL: wss://.ts.netUpstream Token: 你的 Gateway token方案二：SSH 隧道…