超越网

前言 2026年5月，我完成了从 Clash Premium 到 Clash Meta 的迁移。这篇文章记录完整的评测过程，包括功能对比、性能测试和最终选型理由。 一、背景 1.1 为什么需要代理客户端 我的网络环境： 宿主机：fnOS NAS（192.168.0.200），位于国内 VM：Ubuntu 24.04（192.168.0.201），运行各种服务 需求：访问海外API（GitHub、AI供应商）、PT站点、国际新闻源 1.2 为什么选择 Clash Meta 而不是其他 客户端 优点 缺点 Clash Premium 稳定、社区成熟 已停止更新、不支持新协议 Clash Meta 活跃开发、支持新协议 配置稍复杂 Shadowrocket 移动端体验好 仅限iOS、无法服务器部署 v2rayN 功能强大 配置复杂、学习曲线陡 二、功能对比 2.1 协议支持 协议 Clash Premium Clash Meta SOCKS5 ✅ ✅ HTTP ✅ ✅ VMess ✅ ✅ VLESS ❌ ✅ Trojan ✅ ✅ ShadowTLS ❌ ✅ Hysteria2 ❌ ✅ WireGuard ❌ ✅ 结论：Clash Meta 支持所有主流协议，包括最新协议。 ...

前言 2026年5月，我遇到一个反复出现的问题：容器内生成的SSH密钥在容器重启后丢失，导致无法通过SSH连接到宿主机。 这个问题看似简单，但背后涉及Docker容器的文件系统隔离机制。这篇文章记录完整的排查过程和最终解决方案。 一、问题现象 现象：SSH密钥在容器内生成，容器重启后密钥消失，无法连接宿主机 时间：2026-05-18 环境：fnOS虚拟化平台 + Ubuntu 24.04 VM + Docker 初始错误： Warning: Permanently added '192.168.0.200' (ED25519) to the list of known hosts. Permission denied (publickey). 二、根因分析 2.1 Docker容器的文件系统隔离 Docker容器使用联合文件系统（UnionFS），容器内的文件系统是独立的。当容器重启时： 容器内生成的文件 → 存储在容器的可写层 容器重启 → 可写层被销毁，所有未持久化的文件丢失 SSH密钥丢失 → 无法通过密钥认证连接宿主机 2.2 为什么宿主机SSH拒绝使用容器内密钥 即使密钥被挂载到容器，宿主机SSH服务也会拒绝使用： # /var/log/auth.log sshd[12345]: Authentication refused: bad ownership or modes for key file 原因：SSH要求私钥文件所有者必须是 root:root，且权限为 600。容器内生成的密钥，挂载后文件所有者可能不匹配。 三、解决方案 3.1 核心原则 密钥必须在宿主机生成，不能容器内生成。 3.2 完整步骤 步骤1：在宿主机生成SSH密钥 # 宿主机执行（192.168.0.200） ssh-keygen -t ed25519 -C "hermes-agent" -f /home/ksboy/.ssh/hermes_key # 设置权限 chmod 600 /home/ksboy/.ssh/hermes_key chmod 644 /home/ksboy/.ssh/hermes_key.pub 步骤2：将公钥添加到宿主机授权文件 # 宿主机执行 cat /home/ksboy/.ssh/hermes_key.pub >> /home/ksboy/.ssh/authorized_keys chmod 600 /home/ksboy/.ssh/authorized_keys 步骤3：在docker-compose.yml中挂载密钥 services: hermes-agent: image: hermes-agent:latest volumes: # 密钥挂载（只读模式） - /home/ksboy/.ssh/hermes_key:/root/.ssh/id_ed25519:ro - /home/ksboy/.ssh/hermes_key.pub:/root/.ssh/id_ed25519.pub:ro # SSH配置 - /home/ksboy/.ssh/config:/root/.ssh/config:ro environment: - SSH_HOST=192.168.0.200 - SSH_USER=ksboy 步骤4：宿主机SSH配置调整 # /etc/ssh/sshd_config # 允许Docker网段访问 ListenAddress 0.0.0.0 # 重启SSH服务 systemctl restart sshd 3.3 验证 # 容器内测试 ssh -i /root/.ssh/id_ed25519 ksboy@192.168.0.200 "echo '连接成功'" # 重启容器后再次测试 docker-compose restart hermes-agent ssh -i /root/.ssh/id_ed25519 ksboy@192.168.0.200 "echo '重启后连接成功'" 四、关键要点 要点 说明 密钥生成位置 必须在宿主机，容器内生成的密钥重启后丢失 文件所有者 宿主机密钥必须为 root:root（容器以root运行） 挂载模式 使用 :ro 只读模式，防止容器内意外修改 SSH监听地址 宿主机需监听 0.0.0.0，允许Docker网段访问 网络隔离 容器在Docker网段，宿主机在LAN网段，需正确配置路由 五、常见错误 错误1：容器内生成密钥 # ❌ 错误做法 docker exec -it hermes-agent ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 # 容器重启后密钥丢失 错误2：密钥权限不正确 # ❌ 错误做法 chmod 644 /home/ksboy/.ssh/hermes_key # SSH拒绝使用 # ✅ 正确做法 chmod 600 /home/ksboy/.ssh/hermes_key 错误3：宿主机SSH只监听localhost # ❌ 错误做法 ListenAddress 127.0.0.1 # Docker容器无法连接 # ✅ 正确做法 ListenAddress 0.0.0.0 六、总结 SSH密钥持久化的核心是理解Docker的文件系统隔离机制： ...

前言 过去两年，我经历过三次AI服务供应商切换：从最初的单一供应商依赖，到发现限流和成本问题后的多供应商组合，再到现在的"可编程认知系统"架构。 这篇文章记录我当前的AI服务组合架构，以及为什么"单一供应商"在长期生产环境中是一个风险点。 一、当前架构概览 我的AI服务组合由四个供应商组成： 供应商 模型 主要用途 接入方式 智谱AI GLM Coding Lite 代码生成、技术问答 API MiniMax 多种模型 文本生成、创意写作 API DeepSeek DeepSeek-V3 代码审查、复杂推理 API SenseNova 6.7 Flash-Lite 日常协作、多模态 自定义提供商 核心原则：没有单一供应商承担超过40%的工作负载。 二、为什么需要多供应商 2.1 限流风险 2025年Q3，我遇到的第一个限流事件：某供应商在高峰期对API调用实施软限流，返回429错误但不提供明确的重试头信息。当时我的自动化脚本全部阻塞，等待了12分钟才恢复。 教训：单一供应商的限流策略不可控，多供应商可以自动降级。 2.2 成本优化 不同供应商的定价策略差异显著： 简单任务（文本摘要、格式转换）→ 使用低价供应商 中等复杂度（代码审查、技术文档）→ 使用性价比最优供应商 高复杂度（架构设计、深度分析）→ 使用高能力供应商 通过任务路由，整体成本比单一使用高能力供应商降低约35%。 2.3 能力互补 没有哪个供应商在所有任务上都是最优的： 代码生成：GLM Coding Lite 在小型脚本上表现优异 复杂推理：DeepSeek-V3 在多步推理任务上更稳定 创意写作：MiniMax 在中文创意内容上更有表现力 多模态：SenseNova 在图像理解和生成上有独特优势 三、架构实现 3.1 统一接入层 我使用 Hermes Agent 作为统一接入层，配置如下： # config.yaml 片段 providers: - name: glm-coding provider: custom:glm-coding-lite weight: 30 - name: minimax provider: minimax weight: 25 - name: deepseek provider: deepseek weight: 25 - name: sensenova provider: custom:sensenova-6.7-flash-lite weight: 20 3.2 任务路由策略 任务类型 → 路由规则 ───────────────────────────────────── 代码生成 → glm-coding (优先) → deepseek (降级) 技术问答 → deepseek (优先) → glm-coding (降级) 创意写作 → minimax (优先) → sensenova (降级) 多模态 → sensenova (唯一) 日常协作 → sensenova (优先) → 其他 (降级) 3.3 降级机制 当主供应商不可用时，自动切换到备用供应商： ...

前言 银狐病毒（SilverFox）是2022年9月由腾讯安全、360、微步在线三家厂商几乎同时独立发现的针对中国企业的恶意软件家族。与传统的C/C++木马不同，银狐使用 Go语言编写，这带来了独特的检测挑战和特征。 银狐的目标明确：中国企业的财务部门。攻击手法成熟：钓鱼邮件、即时通讯、假冒软件更新。持久化手段多样：注册表、WMI、计划任务、AppInit_DLLs。防御规避专业：篡改Windows Defender排除项、进程注入、随机进程名。 本文基于开源检测工具源代码分析，提供： 银狐的完整感染链分析 Go语言木马的技术特征 增强版YARA规则（覆盖行为特征） 可直接使用的检测脚本 声明: 本文IOC来自开源检测工具源代码，最新IOC请从官方查杀工具获取。 一、银狐病毒技术特征 1.1 Go语言木马的特征 银狐使用Go语言编写，具有以下可检测特征： 特征类型 检测方法 说明 Go运行时库 内存扫描/字符串分析 Go程序加载runtime.dll、go.dll等运行时库 Go二进制结构 PE头分析 Go编译的二进制文件有特定的PE节区（如.go.buildinfo） Go异常处理 行为分析 Go的panic/recover机制与C++异常处理不同 Go协程特征 线程行为 Go的Goroutine调度器会产生特定的线程创建模式 1.2 银狐的行为特征 根据开源检测工具分析，银狐具有以下行为： 1. 进程注入：注入 svchost.exe 等系统进程 2. 注册表持久化：HKCU/HKLM Run键 + AppInit_DLLs 3. WMI事件订阅：__EventFilter + __EventConsumer + __FilterToConsumerBinding 4. 计划任务：创建 Task1 或 SilverFox 相关任务 5. Windows Defender排除：篡改排除路径以规避检测 6. 文件伪装：使用 svchost64.exe、随机进程名（pXDc9LSz.exe） 二、感染链分析 银狐的完整攻击链如下： ┌─────────────────────────────────────────────────────────────────────┐ │ 银狐感染链 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 阶段1: 初始访问 │ │ ├── 钓鱼邮件（伪装成发票、合同） │ │ ├── 即时通讯（微信/钉钉发送恶意文件） │ │ └── 假冒软件更新（财务软件、OA系统） │ │ │ │ 阶段2: 执行 │ │ ├── 用户双击恶意附件 │ │ ├── 恶意宏代码执行 │ │ └── 社会工程学诱导（"文件恢复指南"等） │ │ │ │ 阶段3: 持久化 │ │ ├── 注册表 Run 键写入 │ │ ├── WMI 事件订阅（__EventFilter） │ │ ├── 计划任务创建 │ │ └── AppInit_DLLs 注入 │ │ │ │ 阶段4: 防御规避 │ │ ├── Windows Defender 排除项篡改 │ │ ├── 进程注入（svchost.exe） │ │ ├── 随机进程名生成 │ │ └── 文件伪装（svchost64.exe） │ │ │ │ 阶段5: C2通信 │ │ ├── HTTP/HTTPS 心跳包 │ │ ├── DNS 查询（可能使用DGA） │ │ └── 加密通信（TLS/自定义协议） │ │ │ │ 阶段6: 数据窃取 │ │ ├── 浏览器凭证窃取 │ │ ├── 财务软件凭证窃取 │ │ └── 即时通讯凭证窃取 │ │ │ └─────────────────────────────────────────────────────────────────────┘ 2.1 各阶段检测要点 阶段 检测重点 检测工具 初始访问 邮件附件、钓鱼链接 邮件网关、URL过滤 执行 可疑进程启动 EDR、进程监控 持久化 注册表、WMI、计划任务 注册表监控、WMI监控 防御规避 Defender排除项、进程注入 安全配置审计、内存扫描 C2通信 异常网络连接、DNS查询 网络流量分析、DNS监控 数据窃取 凭证访问、文件外传 DLP、凭证监控 三、IOC 列表（来自开源工具） 以下IOC来自 zseagate/SilverFox-Scanner 和 das-secbox/silverfox_scanner 的源代码。 ...