把一个网站放到云服务器上，最容易让人混淆的并不是 Nginx、证书或域名，而是“我究竟该怎样进入服务器”。 在部署夜有光主站、Nestline 和 Baby Buddy 的过程中，我先后接触了三种阿里云 ECS 连接方式。它们都能把人带到服务器面前，但适合做的事并不相同。

先说结论

连接工具只是通往服务器的入口，不是网站本身，也不是部署程序。关闭这些工具，不会让已经上线的网站停止运行。

连接和部署，是两回事

一次比较完整的静态网站部署，通常包含下面几步：

  1. 01
    本地构建

    把源代码生成浏览器能够直接访问的静态文件。

  2. 02
    传输文件

    把部署包送到 ECS 的临时目录，而不是直接覆盖线上文件。

  3. 03
    服务器检查

    校验文件哈希、备份旧版本，并确认 Nginx 与相关服务状态正常。

  4. 04
    版本切换

    解压到新的版本目录，通过软链接切换，保留随时回滚的旧版本。

  5. 05
    上线验证

    检查 HTTPS、页面资源、真实 404、安全响应头和移动端显示。

Workbench 或 CLI 解决的是第二步到第五步中的“怎样安全地对服务器进行操作”。真正决定部署是否可靠的，仍然是备份、校验、测试和回滚流程。

一张表看懂三种方式

方式最适合主要优点需要留意
网页版 ECS Workbench人工维护、临时排查、首次部署浏览器打开即可使用，终端和文件上传直观会话可能过期，重复操作不易自动化
ali-instance-cli远程终端、端口转发、已有脚本不必开放公网 SSH，可访问服务器内部服务文件传输和结构化自动化能力有限
新版 Workbench CLI重复部署、脚本化运维、AI 工具调用原生支持 exec、upload、download 和 JSON 输出当前主要面向 Linux 实例，并依赖正确的权限与网络配置

01 / BROWSER

网页版 ECS Workbench

这是最适合第一次接触云服务器的方式。进入阿里云控制台，选择实例并打开 Workbench，就能在浏览器里获得终端，也能通过文件任务中心上传部署包。 它不要求先在电脑上安装命令行工具，对偶尔维护网站的人非常友好。

这个网站最初的证书配置、Nginx 检查和静态文件部署，主要就是通过网页版 Workbench 完成的。它最大的优势是“看得见”：上传进度、终端输出和报错都在同一个界面里，适合人在旁边逐项确认。

实践中的限制

浏览器会话可能过期，文件任务也可能因会话失效而中断。部署次数增多以后，反复点击、上传和复制命令会变得低效。

阿里云：通过 Workbench 连接实例

02 / SESSION MANAGER

ali-instance-cli

ali-instance-cli 是阿里云的会话管理命令行工具。它通过云助手和 WebSocket 建立会话，能够在不向公网开放 SSH 端口的情况下进入 ECS。 除了远程终端，它还可以把服务器内部端口临时映射到本机。

.\ali-instance-cli.exe session --instance <实例ID>
.\ali-instance-cli.exe portforward -i <实例ID> -r <远端端口> -l <本地端口>

在本网站的开发过程中，端口转发曾用于从本机安全访问只监听在服务器内部的 Baby Buddy 服务。浏览器访问本机地址，流量经会话通道到达服务器，既不需要把内部端口暴露到公网，也不必改变网站的正式 Nginx 配置。

它是一条临时通道

端口转发依赖正在运行的命令行窗口，窗口关闭后通道就会终止；但服务器上的网站和容器仍会继续运行。

它适合终端连接和端口转发，却不是完整的自动部署工具。身份凭证应使用最小权限的 RAM 用户，不能写入网页源码、部署包、日志或公开仓库。

阿里云：通过 ali-instance-cli 连接实例阿里云：会话管理端口转发

03 / AUTOMATION

新版 Workbench CLI

新版 Workbench CLI 把远程连接进一步变成了可重复调用的运维能力。它不仅能打开交互终端，还提供远程执行、文件上传和文件下载命令，并支持结构化 JSON 输出与远程退出码透传。

workbench connect进入交互式终端
workbench exec执行一条远程命令
workbench upload上传本地文件
workbench download下载服务器文件

这些能力特别适合固定的部署流水线：上传压缩包、验证哈希、创建版本目录、切换软链接、检查 HTTP 状态，并让程序根据每一步的退出码决定是否继续。 对 AI 编程工具而言，JSON 输出也比观察网页终端稳定得多。

AI 能执行，不等于可以省略确认

生产部署仍应保留人工确认、部署前备份、Nginx 语法测试、上线验证和明确的回滚路径。自动化的价值是减少重复劳动，不是取消安全边界。

阿里云：通过 Workbench CLI 连接实例阿里云：使用 Workbench CLI 管理实例

应该怎样选择

偶尔维护，想看清每一步

选择网页版 ECS Workbench。

需要远程终端或临时访问内部端口

继续使用 ali-instance-cli。

经常部署，希望交给脚本或 AI 工具执行

优先考虑新版 Workbench CLI。

三种方式不必互相取代。更现实的组合是：平时用 Workbench CLI 完成重复操作，出现异常时打开网页版 Workbench 人工检查，已有端口转发需求则继续保留 ali-instance-cli。

这次建站留下的部署原则

  • 不向公网开放不需要的管理端口。
  • AccessKey 只属于专用 RAM 用户，并遵循最小权限。
  • 密钥、Token、Cookie、证书私钥绝不进入源码、日志和部署包。
  • 新版本先进入独立目录，校验无误后再切换，不直接覆盖线上文件。
  • 每次变更前留备份，变更后检查 HTTPS、静态资源、安全响应头和真实 404。
  • 自动化命令也要有停止条件，不能因为“能执行”就跳过人工确认。

一开始，我把远程终端理解成“部署工具”。真正做过几次以后才发现，它更像一把钥匙。钥匙决定我们如何进入机房， 但网站能不能稳定上线，取决于进门以后有没有认真核对每一个步骤。