在本地运行Claude Code，体验流畅。但当你把长任务（如全库重构、批量跑测试）迁移到云端VPS时，两个问题会反复出现：SSH一断，进程就被系统杀死；任务跑到一半，内存耗尽被OOM Killer强制终止。这两件事在云端不是偶发的“小毛病”，而是传统SSH会话和虚拟化资源模型与AI编码负载的结构性冲突。
理解冲突的根源，才能把配置做对。
一、SSH断连：为什么进程会跟着终端一起死？
传统SSH会话绑定在一个终端（TTY）上。Claude Code作为前台进程，其生命周期与这个终端紧密耦合。一旦网络抖动导致SSH连接断开，系统会向该会话下的所有进程发送SIGHUP信号，默认行为是直接终止它们。
这意味着，一个已经运行了半小时、消耗了大量Token的长任务，会因为一次Wi-Fi切换而彻底归零。解决方向不是“保持网络永不中断”，而是让进程脱离终端独立存活。
方案一：tmux——交互式会话的“防断连壳”
如果任务需要你偶尔查看进度、干预提示词，tmux是最合适的选择。它的核心价值是维持一个虚拟终端，独立于任何实际连接的SSH会话。
操作流程很直接。SSH登录VPS后，创建命名会话：
tmux new-s claude_agent在tmux界面内正常启动Claude Code。需要下班或网络波动时，按下`Ctrl+B`，松开后按`D`（Detach），你会退回到普通命令行，但Claude Code在tmux后台继续运行。下次连上VPS，执行`tmux attach-t claude_agent`即可回到原现场，进度完整保留。
方案二：systemd用户服务——无人值守的常驻方案
如果Claude Code需要完全无人值守地运行（如定时监听队列、自动化执行任务），tmux的“手动挂起/重连”模式就不够用了。此时应将其配置为systemd用户服务。关键细节：必须是用户服务（`systemctl--user`），而不是系统服务。Claude Code需要读取你的家目录和OAuth凭证，以root或系统服务运行会破坏这些依赖。
首先启用linger，确保用户服务在你退出登录后依然存活：
loginctl enable-linger$USER创建`~/.config/systemd/user/claude.service`，在`[Service]`段中设置`Restart=always`和`RestartSec=10`。这意味着即使Claude Code因偶发错误退出，系统也会在10秒后自动将其拉起。
二、OOM：为什么Claude Code的内存会“失控”？
Claude Code的官方文档明确要求每个会话拥有独立的内存限制。原因在于：当多个会话共享同一个内存上限时，一个会话的内存峰值可能连带杀死其他所有会话，而内核不会按会话粒度决定杀死谁。
GitHub上已有用户报告，单个Claude Code会话的RSS内存可能在8到13分钟内从约300MB持续增长到设定的MemoryMax上限，触发systemd-oomd的终止操作。这不是代码“有bug”，而是AI编码负载的固有特征：上下文持续累积、工具进程常驻、构建和测试步骤会带来瞬时内存峰值。
核心原则：每个会话一个独立的内存上限。
在systemd用户服务中，通过`MemoryMax`为Claude Code划定硬性边界：
ini
[Service]
MemoryMax=8G
MemorySwapMax=5%`MemoryMax`触发的是cgroup级别的精准终止——内核只杀死该服务内的进程，不会波及宿主机上的其他业务。`MemorySwapMax`的作用同样关键：如果不限制Swap，进程在达到内存上限时会优先使用Swap而不是被杀死，内存上限实际上“失效”了。
如果使用Docker容器运行Claude Code，对应的是`--memory`参数或Compose文件中的`mem_limit`。原则相同：每个容器一个会话，每个会话一个内存上限，所有容器的内存上限之和应低于宿主机总内存，为宿主机自身进程留出余量。
附加保护：限制进程/线程数。Claude Code在构建和测试阶段可能启动大量子进程。如果进程数耗尽，新的命令和构建会返回`EAGAIN`（Resource temporarily unavailable）。在systemd服务中通过`TasksMax`设置上限，或在Docker中使用`--pids-limit`，可以避免这一隐性瓶颈。
三、底层的隐形前提：网络质量决定了“防断连”的上限
tmux和systemd解决了进程层面的存活问题，但它们无法消除网络层面的超时重试。Claude Code的工作模式是高频调用云端API，每一次调用都依赖SSH隧道或直连的长连接。如果VPS的回程线路在晚高峰丢包严重，API请求会反复超时，Claude Code进入重试循环，Token消耗和任务时长都会被拉长。
在云端跑Claude Code，配置的核心不是“把服务启动起来”，而是为它建立一个与终端解耦、与资源上限对齐的运行环境。tmux解决交互式会话的存活，systemd用户服务解决无人值守的常驻，`MemoryMax`配合`MemorySwapMax`解决内存失控，而一条低丢包的CN2 GIA线路，让上述所有配置在真实的网络环境下依然能够兑现。
