因此，对您的问题的简短回答是否定的，您无法向所描述的设备发出 HTTP 请求。

原因是为了直接访问设备，客户端（此时您的中央云应用程序将是 HTTP 客户端）需要了解以下内容：

1. 设备的公共路由 IP 地址
2. 设备的固定端口

在您所描述的情况下，您两者都没有。您没有可公开路由的 IP 地址，因为该设备具有无法路由到的私有 (RFC 1918) IP 地址。如果您在路由器上为此设备设置端口转发，则可以使用路由器的外部 IP 地址，但由于大多数家庭宽带提供商不提供固定的 IPv4 地址，因此该地址不会是静态的，并且随时可能发生变化路由器重新启动。您可以让设备在路由器重新启动后每次重新获得网络访问权限时报告，让中央服务知道 IP 地址，但这意味着保留设备位置的实时列表。

您不能使用正常的端口转发有两个原因：

1. 你说你不能依赖你的用户足够精通技术来实际启用它
2. 您如何处理多个设备？每个设备都需要一个单独的端口，并且需要让每个设备知道它们绑定到哪个端口，以便在它们向中央服务报告时可以包含该端口。但这意味着用户不仅必须设置端口转发，还必须为每个设备配置端口信息。

有一种解决方案允许设备设置自己的端口转发，称为 UPnP（通用即插即用），但这需要路由器支持此功能，并且在很大程度上被认为是一个安全漏洞，建议大多数人禁用它.

以上所有就是为什么像 MQTT 这样的协议是物联网设备的事实上的标准。因为设备连接到 MQTT 代理，然后无限期地保持该连接打开，所以避免了我概述的所有问题。

出站连接意味着无需保留设备连接详细信息列表，无需设置任何端口转发，对每个 NAT 路由器后面的设备数量没有限制，无需担心路由器的公共 IP 地址路由器变化。

每个设备订阅特定于其自身的主题（例如，基于设备序列号）并且因此可以接收专门针对该设备的消息，它也可以订阅允许广播类型消息传递的更一般的主题。

如果您的设备运行 Linux 发行版（如 Raspberry Pi），您可以设置反向 SSH 隧道，这样您就可以访问您的设备，即使它位于路由器后面。

这里的问题是您的设备必须启动连接，打开通往服务器的隧道。然后就可以通过服务器连接到设备了。因此，您可以向设备发送一条消息（通过 MQTT 或 HTTP），指示它应该打开反向隧道。

如果您使用的是微控制器（Arduino、ESP8266 等），则必须手动广播您想要的消息，别无选择。

我很好奇你为什么要使用 HTTP 而不是 MQTT？MQTT 的设计目标之一是双向通信。

通过使用 MQTT，您可以为每个设备拥有一个唯一的主题，只有设备本身有权订阅。然后云服务可以向特定于设备的主题发布消息以向该设备发送消息。