OpenClaw 媒体成品链:从下载完成到安全发布
#OpenClaw #qBittorrent #字幕 #媒体自动化 #最小权限 相关:《OpenClaw 微信安全下载体系》 · 《高权限 NAS Skill 静态审计》 · 《OpenClaw 后续功能规划》 下载完成不等于媒体已经适合进入媒体库。真正麻烦的是后半段:验证音轨和字幕、匹配字幕版本、生成不破坏原件的成品、规范命名、保留来源关系,以及识别重复文件。 这次没有接入第三方 NAS Skill 的预编译二进制、私有 API 或 session。它有价值的部分不是“能执行很多命令”,而是先观察、形成计划、绑定对象、返回结构化结果。实际实现全部使用 N100 上可审计的本地 Python 与固定 ffmpeg/ffprobe。 处理链 qBittorrent 完成对象先经过只读观察器。观察器只接受固定分类和下载根目录,并把 infohash、文件清单、字节数和媒体探测结果写入报告。 后续处理遵循四条硬规则: 只有本地确认过的作品别名才能自动生成媒体库名称;未知标题进入人工审核。 原件始终只读,成品只能写入固定的 OpenClaw-Processed。目标已存在就拒...
OpenClaw 模型路由与 Guardian 交接:从手动切换到 Fail-Closed 闭环
#OpenClaw #Guardian #模型路由 #FailClosed 记录 OpenClaw、llama-server、路由 controller 与 GPU Guardian 之间的职责拆分、交接协议和真实恢复闭环。基础安装与 provider 配置见《OpenClaw 配置续集》,当前任务状态见《OpenClaw 后续功能规划》。 一、问题边界 desktop 的 RTX 5080 同时服务本地推理和桌面应用。OpenClaw 默认访问 192.168.2.10:11435 上的 llama-server,但游戏、图像生成和模型测评会占用显存。这里需要解决的不是简单的“进程启停”,而是: 停模型前先把 OpenClaw 切到允许的备用 provider,并排空在途请求; 恢复本地前确认端口、进程、模型身份和上下文参数均正确; 任一步失败都保持云端或停止继续动作,不能留下半切换状态; 人工关闭模型不能被 Guardian 擅自重新拉起。 二、组件职责 组件 唯一职责 明确禁止 Guardian 观察 GPU、冷却时间、所有权和维护窗 ...
Codex 接入 DeepSeek 原生 Responses——503 排查与多推理等级注册
#Codex #DeepSeek #CC Switch #服务器运维 Codex Desktop 通过 CC Switch 接 DeepSeek 的完整收口记录:503 来自旧版本地路由的 Responses→Chat 转换层;DeepSeek 已支持原生 Responses,改直连即可;CC Switch 3.19.2 内置 DeepSeek 官方模型目录(low/high/max 三档推理);Codex Desktop 还需要在「可用推理等级」里启用 max,否则下拉框只显示 low/high。 一、问题现象 Codex Desktop 通过 CC Switch 选择 DeepSeek,请求报: unexpected status 503 Service Unavailable: Unknown error, url: http://127.0.0.1:15721/v1/responses 开启本地路由时,DeepSeek 与 OpenAI 官方接口都不可用 切换到 DeepSeek 后能继承历史会话;切回官方模式时会话为空(provider 索引不一致,属独...
milin_desktop(RTX 5080 16GB)本地 LLM 选型分析
#本地推理 #Ollama #GGUF #RTX5080 #模型选型 硬件背景 组件 规格 GPU NVIDIA GeForce RTX 5080(16GB GDDR7,Blackwell 架构) CPU AMD Ryzen 7 9800X3D(8 核,3D V-Cache) 内存 32GB DDR5 使用场景:为 openclaw agentic 框架 提供本地 LLM 后端,主要执行工具调用、长文档处理、代码生成与分析。对输出速度要求不高(15-30 tok/s 即可),优先质量与上下文长度。 硬件特点: Blackwell 架构原生支持 MXFP4 硬件加速(OpenAI GPT-OSS 专属优势) 9800X3D 的 3D V-Cache 使 CPU 推理带宽远优于同级处理器,CPU offload 惩罚较小 16GB VRAM + 32GB RAM 可做 GPU+CPU 混合推理,允许运行超出 16GB 的模型 完整硬件配置与环境搭建详见 《RTX 5080 新主机环境配置实录》。 候选模型分析 GPT-OSS 20B ...
Windows 旧工作节点最小权限 SSH 与遗留监听治理
#Windows11 #OpenSSH #防火墙 #最小权限 #安全审计 背景与结论 旧工作节点 milin_win11 长期承担过本地模型、OCR、WSL 和远程维护实验。用途变化后,机器上留下了重复 SSH 启动链、失效端口转发、临时模型发布任务、空 Ollama 服务、宽泛第三方入站规则和测试管理员账户。 本轮没有按“看到监听就停服务”的方式处理,而是先建立受限日常入口和独立管理员维护入口,再按账户、任务、端口、规则、模型与安全基线逐项取证。最终完成以下收口: 日常 SSH 使用标准账户 milin_auto,保持非管理员 token,并禁止端口转发;管理员入口仅用于明确维护。 删除失效的 2222/18789 portproxy、模型 blob HTTP 发布任务、重复 SSH 启动任务和过期 WSL 关机任务。 停止空 Ollama 的登录自启动与 LAN 暴露,但保留软件和未来测试所需模型资产。 删除遗留管理员 sshtest,并把 SSH、ASUS、Logitech、Steam 相关入站规则收敛到实际用途。 计划重启后再次验证任务、账户、规则、S...
OpenClaw 后续功能规划与待办任务
#OpenClaw #规划 #待办 记录 OpenClaw 当前运行状态,以及后续可以接入的功能、待解决问题和扩展方向。本文随进展持续更新。 待办维护约定(2026-07-23):当前待办统一维护在跨设备共享的家庭实验室 TODO 源;本文保留规划背景与面向阅读的快照。新事项必须有优先级、状态、依赖、下一步与验收标准,完成后从活动列表移出,避免从旧博客或聊天记录反推状态。 文章边界:本文只维护状态、优先级、依赖、验收结论和专题入口。完整命令、性能矩阵、失败证据与清理清单以对应专题为准,避免规划快照成为第二份实施记录。 分流/审核状态(2026-08-10):OC-06 已完成非生产分类评测;OC-07 的 deterministic PoC 已通过,但 Qwen3-4B 在冻结 3 秒门禁下不晋级。两者都只是建议层,不能替代确定性规则、显式审批或工具执行门禁。生产状态以共享 TODO 为准。 本系列:部署实录 · 配置续集 · 模型路由与 Guardian · Exec 审批治理 · 公网访问 · Headroom 接入 · 本地记忆与无审批能力边界 · 微信安全...
N100 NAS Observer 能力扩展:固定诊断、SMART 与恢复预览
#OpenClaw #NAS #SMART #最小权限 最小权限不是把功能永久停在“只能看容量”。更实用的目标是最大安全权限包络:尽量增加诊断能力,但把身份、对象、路径、副作用、回执和回滚全部冻结。 基础快照隔离架构见 《N100 只读 NAS Observer:从高权限 Skill 到快照隔离》。本文只记录后续能力扩展。 一、从五个查询扩展到十七个工具 扩展后的能力分为三组: 九个只读投影:宿主资源、存储、磁盘、SMART 脱敏摘要、共享、Docker 状态、定时任务、统一风险和综合诊断; 固定诊断动作:即时刷新、受控临时写探针、脱敏诊断包、SMART short 计划/启动/状态、配置 preview; 服务恢复 preview:生成对象哈希、身份绑定、十分钟 TTL、单次使用、前后置检查和自动回滚方案,但不开放生产执行。 OpenClaw 仍然没有 Docker socket、root、通用命令、任意路径、凭据或第三方网络。容器日志也不是任意查询,只在宿主端按固定窗口归约为 error、timeout、OOM、storage 等计数,原文不进入快照。 二...
N100 只读 NAS Observer:从高权限 Skill 到快照隔离
#OpenClaw #NAS #Docker #最小权限 高权限 NAS Skill 未通过供应链与权限门禁,不代表 Agent 只能完全放弃 NAS 可观测性。更安全的做法是把宿主探测和 Agent 工具隔开:宿主定时生成脱敏快照,OpenClaw 只读快照,并只暴露固定无参数查询。 前置审计与不晋级原因见 《高权限 NAS Agent Skill 静态审计:为什么“有确认”仍不足以接入生产》。 一、目标不是移植 fnOS 当前 N100 同时承担 Ubuntu Docker 宿主和 NAS 职责,但它不是 fnOS。原 Skill 依赖 fnOS 私有 API、session 和预编译 CLI,直接移植既不适配,也会把文件、Docker、用户和存储写能力一并带入 Agent。 本阶段只保留五种只读意图: nas_status:容量与容器健康摘要; nas_storage:固定挂载点容量; nas_disks:块设备结构,不含序列号; nas_shares:固定共享挂载状态,不含远端 source; nas_containers:名称、镜像标识、运行状态...
OpenClaw Exec 审批与生命周期治理:最小权限、等待状态与微信回传
#OpenClaw #Exec审批 #最小权限 #微信 记录 OC-05 的生产审批基线、D2b 审批等待缺陷和 OC-22 微信文本式审批边界。基础插件配置见 《OpenClaw 配置续集》,无审批日常能力见《OpenClaw 本地记忆落地与无审批能力边界》,任务状态见《OpenClaw 后续功能规划》。 一、为什么不能用“始终允许”解决 OpenClaw 的 exec 能触达 shell、网络、Docker 和宿主机文件。把下载或邮件中的一个审批问题转化为通用 shell 放行,会让自然语言、网页内容和 prompt injection 获得远超任务所需的能力。 当前原则是: 123信息获取与固定只读快照 → 无审批有限参数、可验证、可回滚的动作 → 精确 allowlist外发、删除、系统变更和通用执行 → 人工确认 审批模型或语义分类器只能补充风险提示,不能替代确定性的权限策略。 二、生产审批基线 实际生效文件位于 OpenClaw 的容器数据挂载中,而不是顶层历史配置。生产基线已统一为: defaults、main、download、heartbeat:allo...
高权限 NAS Agent Skill 静态审计:为什么“有确认”仍不足以接入生产
#OpenClaw #Agent-Skill #供应链安全 #NAS 本文记录一次只做静态取证的高权限 NAS Skill 审计。结论不是“发现恶意代码”,而是:在来源、许可证、构建链和宿主侧权限治理均无法闭合时,功能再完整也不应直接接入生产 Agent。 一、审计边界 目标制品来自厂商官方论坛附件,包含一份 Skill 文档、模块参考、三个平台 wrapper,以及 macOS、Linux、Windows 五个预编译 CLI。审计期间坚持四条边界: 不安装、不执行、不导入 Agent; 不连接 NAS、OpenClaw 或其它生产服务; 文本复制到隔离目录,二进制只在原下载目录做格式、签名、字符串和 SHA-256 取证; 文件清单、字节数和哈希必须逐项复算。 制品共 34 个文件,约 26 MiB,其中五个二进制占绝大部分。隔离目录只保留 29 个文本文件,没有二进制落入后续工作区。 二、供应链先于功能 manifest 声明版本为 0.1.0,但制品没有提供: 源码仓库; 精确 commit 或 tag; LICENSE、COPYING、...
OpenClaw 微信安全下载体系:确定性 Gate 与 qB 隔离
#OpenClaw #qBittorrent #最小权限 #网络隔离 记录 OC-23:让微信里的“帮我下载 X”能够进入自动化流程,同时不把网页文本、模型判断或一个 magnet 直接等同于下载权限。 相关笔记:《OpenClaw 本地记忆落地与无审批能力边界》 · 《OpenClaw Exec 审批与生命周期治理》 · 《OpenClaw 后续功能规划》 · 《N100 安全事件响应与 fail2ban 加固》 一、问题不在 qB API,而在权限兑换 qBittorrent 的新增、暂停、恢复和删除接口并不复杂。真正危险的是这条隐含链路: 1网页内容 → 模型相信它 → 直接调用下载接口 搜索结果和网页正文都可能包含 prompt injection,也可能指向内网、重定向到不同主机,或提供与页面描述不一致的 torrent。仅靠 system prompt 要求模型“注意安全”,不能形成可审计的权限边界。 因此这轮把流程拆成三个角色: 1download-discovery → download coordinator → deterministic Gate → ...
N100 系统盘取证恢复与安全启动重构
#N100 #数据恢复 #Docker #systemd #ext4 #btrfs 背景与结论 N100 出现开机即卡死、反复重启并最终无法进入系统。原 128 GB NVMe 被取出,通过 Mac 做只读取证、镜像和文件系统恢复,再克隆到 256 GB NVMe。新盘已经成功从 N100 启动,SSH、系统盘和 Docker 基础能力均通过验证。 本轮能够确认的是: 原系统盘 ext4 存在由异常断电/硬重启留下的 journal、inode bitmap、free count 和 checksum 不一致;修复后连续两次只读检查干净。 原盘完整镜像和独立回读校验一致,ddrescue 未报告读错误或坏扇区。 新 256 GB NVMe 的系统分区和文件系统已扩容,当前根分区约 234 GiB。 旧启动链把 USB 外盘挂载和 Docker 放进主机启动关键路径,会放大外盘、USB 或文件系统异常的影响;现已解耦。 现有证据不能把唯一根因锁定为 Btrfs、Wi-Fi 或某个硬件部件。ext4 损坏是确定事实,但 USB/硬盘柜/供电等因素仍需观察。 旧...
N100 网络重构与服务修复记录
#Docker #WebDAV #frp #Samba #openclaw #服务器运维 背景 路由器设备更换,局域网网段从 192.168.0.0/24 整体迁移至 192.168.2.0/24。N100 重启后各服务需要恢复,同时处理 openclaw 权限修复遗留的路径问题、WebDAV 公网访问故障及 LLM 连接问题。 文章边界:本文是“网段迁移后的整体恢复”事件记录,按同一恢复窗口组织而非作为 WebDAV、Samba、OpenClaw 或代理的长期配置手册。事件闭环后只补勘误、最终状态和专题链接。 本文涉及的 openclaw 权限修复遗留问题,源自 《N100 安全事件响应:OpenClaw SSH 暴力破解与 fail2ban 加固》。 一、磁盘检查与挂载恢复 btrfs RAID1 健康验证 2026-08 复核更正: 本节的 no error found 只代表当次检查结果。后续完整只读检查已发现 free-space-tree/space-info 不一致;当前策略是先备份,再只读治理,禁止在唯一副本上执行 btrfs check --repa...
OpenClaw 公网访问:FRP + nginx HTTPS 配置实录
#OpenClaw #FRP #nginx #HTTPS #公网访问 接上篇 《OpenClaw 配置续集:网络修复、邮件插件与 Ollama 接入》,记录第三阶段:为 OpenClaw 配置公网 HTTPS 访问。 文章边界:本文的权威范围是 FRP、nginx、TLS、浏览器 Origin 与设备配对组成的公网访问链路。文中保留的环境变量、CLI 写入和 ollama.auth 故障是当时的连带排障证据;后续通用配置问题应转入对应专题,本文只补充公网链路的勘误或验收结果。 一、整体架构 123456789101112131415用户浏览器 │ HTTPS 443 ▼MyServer(Aliyun 公网,x.x.x.x) └── nginx 反向代理 → 127.0.0.1:17890 │ ▼ frps(已运行,bind_port=6000) │ FRP 隧道 ▼N100(本地,192.168.0.155) └── frpc → 127.0.0.1:18789 │ ...
OpenClaw 配置续集:网络修复、邮件插件与 Ollama 接入
#OpenClaw #Docker #Ollama #邮件插件 #网络排障 接上篇 《N100 自托管 OpenClaw + Hermes Agent 部署实录》,记录第二阶段的配置与踩坑;后续任务见 《OpenClaw 后续功能规划与待办任务》。 文章边界:本文已作为“基础配置第二阶段”历史实录冻结。邮件、早期 Ollama 和 llama-server 迁移保留当时的完整过程;新的模型路由、执行审批、微信投递和本地记忆只更新各自专题,本文不再追加跨主题实施章节。 一、修复 Docker 容器无法访问公网 WAN TCP 现象 容器内 ping 1.1.1.1 正常(ICMP 通),但 curl https://api.deepseek.com 超时。导致 DeepSeek / Anthropic API 全部失败,日志输出: 1Error: All models failed (2): deepseek/deepseek-chat: LLM idle timeout (120s) 根本原因 N100 使用 WiFi(wlp2s0)上网。Docker bridge 模...
MyUbuntu 服务关机与启动流程
#Docker #btrfs #systemd #服务器运维 2026-08 更新: 本文记录的是旧自动挂载方案,已不再用于当前 N100。外盘现改为 noauto,nofail,Docker 与外盘均退出主机启动关键路径。独立 Rescue U 盘虽通过第一轮静态结构验收,但后续发现包管理内容损坏,当前禁止启动、设置 BootNext 或执行真实镜像。请勿在当前主机照搬下文的 ext-mount.service 和 mount-retry.sh;现行设计、恢复过程与 Rescue 门禁见 《N100 系统盘取证恢复与安全启动重构》。 磁盘与挂载结构 设备 容量 类型 挂载点 说明 sda (SSD) 119G ext4 / 系统盘,已用 93% sdb (WD 4T) 3.6T exfat /smb 外部硬盘,影视/文件共享 sdc (WD 2T) 1.8T btrfs /nfs btrfs 多设备卷成员 1 sdd (2T) 1.8T btrfs —(内核接管) btrfs 多设备卷成员 2 btrfs 卷说明 sdc 与 sdd 共享同一...
N100 安全事件响应:OpenClaw SSH 暴力破解与 fail2ban 加固
#安全 #fail2ban #frp #N100 #运维 背景 排查 N100(Ubuntu 22.04)开机卡死问题时,发现系统存在持续 11 天的 SSH 暴力破解,来源为内部 Docker 容器(openclaw),同时 frp 内网穿透服务将 SSH 端口暴露在公网,导致来自外部的 SSH 探测。本文记录整个事件的发现、处置和加固过程。 事件时间线 时间 事件 7月4日 N100 正常运行 7月5日 openclaw 容器开始向本机 SSH 发起字典攻击 7月16日 攻击最后记录(7月17日重启后 openclaw 未随 boot 自启) 7月17日 N100 多次开机卡死;排查发现 ext-mount.service 因外接 btrfs 盘状态异常导致内核挂起 7月17日 停止 openclaw 容器;分析 SSH 日志;配置 fail2ban 7月17日 实施 openclaw 容器安全加固(非 root 用户、bridge 网络、SSH wrapper、AGENT.md 信任等级) 7月17日 卸载 Neo4j(端口 7687...
SDSC6001 作业 1:覆盖数泛化界
SDSC6001 作业1:覆盖数泛化界 问题:证明覆盖数界并通过模拟验证 背景(给定) 设 H\mathcal{H}H 是从 X\mathcal{X}X 映射到 Y⊆R\mathcal{Y} \subseteq \mathbb{R}Y⊆R 的函数族。我们考虑平方损失: ℓ(h(x),y)=(h(x)−y)2\ell(h(x), y) = (h(x) - y)^2 ℓ(h(x),y)=(h(x)−y)2 设 DDD 是 X×Y\mathcal{X} \times \mathcal{Y}X×Y 上的未知分布。对于 h∈Hh \in \mathcal{H}h∈H,定义真实风险和经验风险: R(h)=E(x,y)∼D[(h(x)−y)2],R^S(h)=1m∑i=1m(h(xi)−yi)2R(h) = \mathbb{E}_{(x,y)\sim D}[(h(x) - y)^2], \quad \hat{R}_S(h) = \frac{1}{m}\sum_{i=1}^{m}(h(x_i) - y_i)^2 R(h)=E(x,y)∼D[(h(x)−y)2],R^S(h)=m1i=1∑m...
SDSC6001 Assignment 1: Covering-Number Generalization Bound
SDSC6001 Assignment 1: Covering-Number Generalization Bound Problem: Prove a covering-number bound and verify it by simulation Background (given) Let H\mathcal{H}H be a family of functions mapping X\mathcal{X}X to Y⊆R\mathcal{Y} \subseteq \mathbb{R}Y⊆R. We consider the squared loss ℓ(h(x),y)=(h(x)−y)2\ell(h(x), y) = (h(x) - y)^2 ℓ(h(x),y)=(h(x)−y)2 Let DDD be an unknown distribution over X×Y\mathcal{X} \times \mathcal{Y}X×Y. For h∈Hh \in \mathcal{H}h∈H, define the true risk and empirical risk...
OpenClaw 本地记忆落地与无审批能力边界
#OpenClaw #本地Embedding #执行审批 #最小权限 记录 OC-21 的最终结果:恢复 Web 检索与容器网络,部署纯本地 embedding,并重新评估 OpenClaw 在不弹出 exec 审批时能否覆盖日常使用。 相关笔记:《OpenClaw 后续功能规划》 · 《OpenClaw 配置续集》 · 《OpenClaw Exec 审批与生命周期治理》 · 《N100 安全事件响应与 fail2ban 加固》 · 《OpenClaw 微信安全下载体系:确定性 Gate 与 qB 隔离》 一、这轮解决了什么 1. Web 检索与代理恢复 替换过期代理节点后,清理了重复导入项,并把 Docker 网桥使用的代理 forwarder 从临时 Python 进程改为受 systemd 管理的用户服务。DuckDuckGo 插件完成两组独立合成检索,web_fetch 也通过公开网页验收。 Node 24 需要显式启用环境代理。微信 API 走代理,而局域网 llama-server 使用 NO_PROXY 中的精确主机 192.168.2.10 直连。这里不能只...
个人健身预约系统:从业务建模到 Alpha 验收
#FastAPI #Vue #PostgreSQL #Docker #预约系统 #软件测试 记录一个面向个人健身教练的预约系统如何从网页版 Demo 演进到可公开测试的 Alpha:业务角色、预约与履约状态、敏感数据、日程可视化、验收数据和部署安全。 一、目标与边界 项目先交付移动优先的网页版,未来再迁移到微信小程序。首版不接入付费短信、在线支付和跨教练调度,登录使用账号密码;微信版本再切换到微信认证。 核心角色分为: 学员:注册、预约、取消、查看训练记录、上传饮食记录; 教练:发布时段、设置休息、代客预约、确认履约或爽约、维护学员档案; 管理员:审批教练、管理人员绑定、维护课程和全局配置; 多身份用户:不退出登录即可切换教练与管理员工作区。 技术栈最终采用 Vue 3、FastAPI、PostgreSQL、Docker Compose 和 nginx。相比 Flask, FastAPI 的类型模型、请求校验和自动生成 OpenAPI 的能力更适合接口较多、准备迁移到小程序的项目;生产环境则关闭公开 API 文档。 二、核心实体关系 主要实体包括用户、角色...
OpenClaw 微信文件投递踩坑:iLinkai API 大小写陷阱
#OpenClaw #微信 #调试踩坑 记录一次通过微信发送文件附件(xlsx)时遭遇的连环报错,以及最终定位到 iLinkai API 大小写敏感问题的全过程。 本系列:部署实录 · 配置续集 · 公网访问 · Headroom 接入 · 后续规划 背景 用 OpenClaw Agent 生成了一份评分标准表格(.xlsx),希望通过微信渠道直接投递给对话方,无需额外步骤。整个流程应该是: Agent 调用 message 工具,指定 media 参数(文件路径) openclaw-weixin 插件将文件上传到 iLinkai CDN CDN 地址写入微信文件消息,发送给对方 听起来很顺,实际踩了好几个坑。 一、连环报错 报错 1:sendMessage ret=-3 errmsg=invalid arguments 1[tools] message failed: sendMessage ret=-3 errmsg=invalid arguments 原因:指定了错误的 accountId——两个机器人账号中,目标用户只与其中一个有聊天记录,用了另一...
Claude Code 记忆同步进阶——canonical 软链、白名单 .stignore 与跨工作区 skill
#ClaudeCode #Syncthing #开发环境 #服务器运维 上一篇用 Syncthing 打通了三端 ~/.claude/,但直接同步各工作区的 memory/ 目录会遇到一个坑:不同设备的工作区路径编码不一样。本文记录把记忆层重构成 canonical _shared/ + 软链、把 .stignore 从黑名单改成白名单,并新增两个跨工作区 skill 与记忆治理约定的过程——一次完整的"开发环境梳理"。 一、上一版留下的坑:per-encoding 路径错位 Claude Code 把每个工作区的记忆存在 projects/<路径编码>/memory/ 下,而路径编码含绝对路径: Mac:projects/-Users-lin-infra/memory/ Windows:projects/C--Users-milin-infra/memory/ 同一个 ~/infra 工作区,两台机器编码不同。若直接同步 projects/*/memory,两端各写各的目录,记忆根本对不上,同步等于白做。 二、方案:canon...
milin_desktop v2rayA 点启动弹错——孤儿 core 占端口排查
#v2rayA #Windows #nssm #服务器运维 milin_desktop 上的 v2rayA 突然用不了,Web UI 点"启动"就弹报错。排查发现既不是网络问题也不是后端挂了,而是上一次残留的 xray-core 进程变成孤儿、一直霸占入站端口,导致新 core 起不来。记录定位过程与用 nssm 事件钩子防复发的做法。 环境 主机:milin_desktop(Windows 11,192.168.2.10) 安装:D:\Program Files (x86)\v2raya\,以 nssm 注册成服务 v2raya(--lite --v2ray-bin ...\v2ray.exe) core:实为 xray-core 2.4.6 Web UI:http://192.168.2.10:2017 日志:安装目录 v2raya-stdout.log / v2raya-stderr.log(nssm 重定向) 配置/资产目录:C:\Users\milin\AppData\Roaming\v2rayA 一、症状与初判 ...
Claude Code 多设备记忆同步——Syncthing 方案实录
#ClaudeCode #Syncthing #Windows #开发环境 #服务器运维 同一用户在 Mac、N100、Windows 三台设备上使用 Claude Code CLI,各自的 ~/.claude/ 完全独立,导致跨设备会话反复重建上下文、浪费 token。本文记录用 Syncthing 打通三端记忆层的完整方案,以及在会话中主动向同步体系注入信息的方法。 一、问题描述 Claude Code 的跨会话记忆存储在 ~/.claude/ 下,核心是各项目的 memory/ 目录: 123456789~/.claude/ projects/ -Users-lin-Documents-MyBlog/ memory/ MEMORY.md ← 索引 project_homelab_infra.md ← 设备拓扑、服务配置 feedback_openclaw_*.md ← 排查经验 settings.json ← 全局设置 plugi...
