Octopus Deploy 的部署体系里，Octopus Server 负责编排流水线、管理变量和审批，而真正在目标机器上执行部署动作的是 Tentacle。这个代理服务一旦与 Server 的连接出现问题，再完善的部署流程也无法推进。因此，搞清 Tentacle 与 Server 的通信方式，对日常排障和架构设计都很有价值。
一、两种通信模式：监听与轮询
Tentacle 在设计上支持两种工作模式：Listening（监听）和 Polling（轮询）。Listening 模式下，Tentacle 在目标机器上监听 TCP 10933 端口，Octopus Server 需要主动向该端口发起 HTTPS 连接。这要求服务器所在网络能够路由到目标机器，并且目标机器的防火墙必须放行入站 10933 端口。该模式配置直观，适合内网环境，所有目标机器都在同一可信网络内。
Polling 模式则反过来：Tentacle 启动后主动向 Octopus Server 的 443 或 80 端口发起出站 HTTPS 连接。连接建立后保持长连接，Server 通过该连接将任务推送给 Tentacle。目标机器不需要开放任何入站端口，因此非常适合云主机、DMZ 隔离区或 NAT 后的机器。只要出站网络能到达服务器，Tentacle 就能工作。缺点是需要保证服务器地址稳定，并且要处理代理和重连逻辑。
下面这张表可以更直观地对比两种模式的关键差异。
| 对比项 | Listening 模式 | Polling 模式 |
|---|---|---|
| 连接方向 | Server 主动连接 Tentacle | Tentacle 主动连接 Server |
| 默认端口 | 10933（入站） | 443 或 80（出站） |
| 防火墙要求 | 目标机器需开放入站 10933 | 目标机器无需开放入站端口 |
| 适用场景 | 内网、网络互通环境 | DMZ、云主机、NAT 隔离环境 |
| 服务重连 | 依赖 Server 重试连接 | Tentacle 自动重连，兼容代理 |
无论选择哪种模式，Tentacle 的安装与配置都可以通过命令行完成。下面是一个 Listening 模式的典型配置序列。
Tentacle.exe create-instance --instance "Tentacle" --config "C:\Octopus\Tentacle.config" --console Tentacle.exe new-certificate --instance "Tentacle" Tentacle.exe configure --instance "Tentacle" --home "C:\Octopus" --app "C:\Octopus\Applications" --port 10933 --noListen "False" Tentacle.exe configure --instance "Tentacle" --trust "SERVER_THUMBPRINT" Tentacle.exe service --install --start
二、TLS 握手与证书身份验证
Tentacle 与 Server 之间所有交互都走 HTTPS，底层使用 TLS 加密。Octopus 使用自签名 X.509 证书来实现双向认证。Tentacle 第一次初始化时生成自己的证书，Server 也有自己的证书。在注册目标机器时，管理员需要把 Tentacle 的证书指纹添加到 Octopus Server 中，Tentacle 端也要配置信任 Server 的证书指纹。通信时双方会校验对端指纹，只有完全匹配才继续握手，否则直接断开。
证书指纹是一个 40 位十六进制字符串。可以使用 Tentacle.exe 的 show-thumbprint 命令查看。注册时，Octopus Server 会存储该指纹。在后续的连接中，Tentacle 证书保持不变，因此即使网络中的其他主机冒充目标机器，也会因为证书指纹不匹配而失败。证书过期问题也不容忽视，自签名证书默认有效期较长，但一旦到期，所有通信都会中断，需要重新生成证书并重新注册。
配置 Polling 模式时，需要同时指定服务器地址和 API Key，Tentacle 会在注册过程中完成证书信任。下面是常见命令示例。
Tentacle.exe create-instance --instance "Tentacle" --config "C:\Octopus\Tentacle.config" --console Tentacle.exe new-certificate --instance "Tentacle" Tentacle.exe show-thumbprint --instance "Tentacle" Tentacle.exe configure --instance "Tentacle" --home "C:\Octopus" --app "C:\Octopus\Applications" --noListen "True" Tentacle.exe configure --instance "Tentacle" --server "https://octopus.deploy.local" --apikey "API-XXXX" Tentacle.exe service --install --start
三、任务消息与部署执行流程
当操作员在 Octopus 界面上点击 Deploy 时，Server 会创建部署任务，并将任务描述序列化为 JSON 消息。如果是 Polling 模式，Tentacle 会在长连接上收到任务；如果是 Listening 模式，Server 会向目标机器的 10933 端口发起连接并发送任务。任务消息中包含步骤列表、变量值、包版本和敏感数据等。Tentacle 收到任务后不直接执行脚本，而是拉起一个名为 Calamari 的执行器子进程。
Calamari 负责下载制品、解析执行 PowerShell 或 Bash 脚本、上传日志。日志流通过 Tentacle 与 Server 的连接实时回传，因此界面上的部署输出几乎同步。制品下载则不一定经过 Server。如果制品存储在内置仓库，Tentacle 会从 Server 拉取；如果配置了外部制品源或共享目录，Tentacle 会直接访问对应地址。这也解释了为什么有时 Tentacle 与 Server 连通，但部署因下载制品失败而卡住。
健康检查是通信链路的定期验证。Server 周期性地发送一个轻量任务，Tentacle 执行后回报状态、磁盘空间和权限信息。如果健康检查失败，通常是证书、服务状态或网络抖动。排查时可以先查看 Tentacle 日志。
Get-Content C:\Octopus\Logs\Tentacle.txt -Tail 50
四、常见通信故障排查
通信类故障大多集中在连接超时、证书不匹配、TLS 版本不兼容和代理配置错误。先确认 Tentacle 服务是否运行，以及模式配置是否正确。Listening 模式检查端口 10933 是否被监听，Polling 模式检查 Tentacle 是否成功注册并保持连接。使用 Test-NetConnection 可以快速判断端口可达性。
证书相关错误会在 Tentacle 日志中留下明显的 SSL/TLS 异常。如果日志中出现 Fingerprint 不匹配或 certificate validation failed，需要对比 Tentacle 证书指纹与 Octopus Server 中保存的指纹。如果服务器使用反向代理或负载均衡，需要确保代理不会替换证书，且原证书链被 Tentacle 信任。TLS 版本方面，较新的 Octopus 版本默认要求 TLS 1.2 以上，旧系统可能需要升级才能正常通信。
下面几条命令可以覆盖大部分基础排查场景。
Test-NetConnection -ComputerName tentacle01 -Port 10933 curl -Iv https://tentacle01:10933 Get-Content C:\Octopus\Logs\Tentacle.txt -Tail 50
总体来看，Tentacle 与 Server 的通信并不复杂，但涉及网络模式、证书信任和任务流三个层面。理解清楚后，遇到连接类问题就能按顺序排查，不必盲目重启服务。优先选择 Polling 模式可以减少目标机器的入站暴露面，同时保持日志和证书的有效期管理，能显著降低部署链路的故障率。
Octopus Tentacle服务器通信部署代理修改时间：2026-09-28 16:34:55