Caddy 反向代理 curl 内部工作正常，但外部返回 content-length: 0

Question 1

我认为这是由于地址匹配器的工作方式所致。请注意，在第一个记录中（在 HTTP 请求中）：

GET / HTTP/2
Host: 192.168.1.5

https://192.168.1.5:443与Caddyfile成功匹配，但第二个记录Host有所不同：

GET / HTTP/2
Host: 203.0.113.0

而 Caddyfile 中没有任何内容可以匹配它。因此，这种行为是意料之中的。

您可以通过使用 Curl 设置任意Host标头来检查这一点192.168.1.5：

curl -H "Host: 192.168.1.5" -vk https://203.0.113.0/

这可以从外部工作，但 SNI 主机名也可能存在问题，它仍将设置为203.0.113.0。我不确定，但curl -vk --resolve 192.168.1.5:443:203.0.113.0 https://192.168.1.5/在这种情况下添加可能会有所帮助（它设计为与主机名一起使用，例如curl --resolve example.com:443:127.0.0.1 https://example.com/...；我不知道它是否能够将 IP 地址“解析”为另一个 IP 地址）。

如何修复这个问题？您可以尝试将其他主机匹配项添加到此块：

https://192.168.1.5:443, 203.0.113.0 { ... }

我没有检查这个，但我相信第一个将设置绑定，而第二个只是为了匹配标题Host。

但是，我认为最好不要通过原始 IP 地址访问 HTTPS 服务器。使用名称。

Answer

我认为这是由于地址匹配器的工作方式所致。请注意，在第一个记录中（在 HTTP 请求中）：

GET / HTTP/2
Host: 192.168.1.5

https://192.168.1.5:443与Caddyfile成功匹配，但第二个记录Host有所不同：

GET / HTTP/2
Host: 203.0.113.0

而 Caddyfile 中没有任何内容可以匹配它。因此，这种行为是意料之中的。

您可以通过使用 Curl 设置任意Host标头来检查这一点192.168.1.5：

curl -H "Host: 192.168.1.5" -vk https://203.0.113.0/

这可以从外部工作，但 SNI 主机名也可能存在问题，它仍将设置为203.0.113.0。我不确定，但curl -vk --resolve 192.168.1.5:443:203.0.113.0 https://192.168.1.5/在这种情况下添加可能会有所帮助（它设计为与主机名一起使用，例如curl --resolve example.com:443:127.0.0.1 https://example.com/...；我不知道它是否能够将 IP 地址“解析”为另一个 IP 地址）。

如何修复这个问题？您可以尝试将其他主机匹配项添加到此块：

https://192.168.1.5:443, 203.0.113.0 { ... }

我没有检查这个，但我相信第一个将设置绑定，而第二个只是为了匹配标题Host。

但是，我认为最好不要通过原始 IP 地址访问 HTTPS 服务器。使用名称。

Question 2

Nikita Kipriyanov 的回答是正确的；我只是添加这个来显示我的最终配置是什么样的。

解释

正如尼基塔所说：

...在第二段文字中，主持人有所不同：
GET / HTTP/2
Host: 203.0.113.0
而 Caddyfile 中没有任何内容可以匹配它。因此，这种行为是意料之中的。

事实证明问题出在我的 Caddyfile 上。我错误地配置了我的网站地址；Caddy 返回了一个没有内容的响应，因为它与提供的任何路由都不匹配。我的文件的最终结构如下所示：

{
        default_sni 192.168.1.5
}

https://203.0.113.0:443, https://192.168.1.5:443 {

        handle /static/* {
                root * /srv
                file_server browse
        }

        handle /foundry/* {
                reverse_proxy /foundry/* localhost:30000
        }

        handle /foundry {
                reverse_proxy /foundry localhost:30000
        }

        handle {
                reverse_proxy * localhost:8000
        }
}

我学到了一些重要的东西：

从路由器转发的请求不会将 Host 标头更改为内部 IP 地址；它只是将整个请求转发到内部 IP 地址。因此，https://192.168.1.5Caddy 收到的不是路由的请求，而是路由的请求https://203.0.113.0。由于没有路由https://203.0.113.0，它只是发回了一个空白页。
路由器配置为监听端口:580并将请求转发到192.168.1.5:443。我在最初的问题中忽略了这个细节。需要注意的是，要匹配的站点地址上的端口是不是路由器上打开的外部端口；这是 Caddy 在运行 Caddy 的机器上监听的端口。这让我很困惑，因为我正在将路由器上的端口 580 转发到机器上的端口 443，但为了让 Caddy 匹配路由，我不能使用它https://203.0.113.0:580（我在之前的故障排除中曾尝试过将其作为路由）；它必须是https://203.0.113.0:443。

结论

如果您使用的是 IP 地址而不是域名，请确保外部 IP 的路由遵循以下形式：

<http | https>://<external IP>:<port that Caddy is listening on>

Answer

Nikita Kipriyanov 的回答是正确的；我只是添加这个来显示我的最终配置是什么样的。

解释

正如尼基塔所说：

...在第二段文字中，主持人有所不同：
GET / HTTP/2
Host: 203.0.113.0
而 Caddyfile 中没有任何内容可以匹配它。因此，这种行为是意料之中的。

事实证明问题出在我的 Caddyfile 上。我错误地配置了我的网站地址；Caddy 返回了一个没有内容的响应，因为它与提供的任何路由都不匹配。我的文件的最终结构如下所示：

{
        default_sni 192.168.1.5
}

https://203.0.113.0:443, https://192.168.1.5:443 {

        handle /static/* {
                root * /srv
                file_server browse
        }

        handle /foundry/* {
                reverse_proxy /foundry/* localhost:30000
        }

        handle /foundry {
                reverse_proxy /foundry localhost:30000
        }

        handle {
                reverse_proxy * localhost:8000
        }
}

我学到了一些重要的东西：

从路由器转发的请求不会将 Host 标头更改为内部 IP 地址；它只是将整个请求转发到内部 IP 地址。因此，https://192.168.1.5Caddy 收到的不是路由的请求，而是路由的请求https://203.0.113.0。由于没有路由https://203.0.113.0，它只是发回了一个空白页。
路由器配置为监听端口:580并将请求转发到192.168.1.5:443。我在最初的问题中忽略了这个细节。需要注意的是，要匹配的站点地址上的端口是不是路由器上打开的外部端口；这是 Caddy 在运行 Caddy 的机器上监听的端口。这让我很困惑，因为我正在将路由器上的端口 580 转发到机器上的端口 443，但为了让 Caddy 匹配路由，我不能使用它https://203.0.113.0:580（我在之前的故障排除中曾尝试过将其作为路由）；它必须是https://203.0.113.0:443。

结论

如果您使用的是 IP 地址而不是域名，请确保外部 IP 的路由遵循以下形式：

<http | https>://<external IP>:<port that Caddy is listening on>

Caddy 反向代理 curl 内部工作正常，但外部返回 content-length: 0

背景与问题

网络设置

`curl`结果

使用内网IP时的输出

使用外部IP时的输出

Caddy文件

答案1

答案2

解释

结论

相关内容