☰

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

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

背景与问题

我正在尝试将 Caddy 设置为两个其他 Web 应用程序和一个静态文件服务器（都在一台机器上）之间的反向代理。当我使用curl内部 IP 时，它按预期工作，但当我尝试使用curl外部 IP 时，它返回content-length: 0。最终，我的问题是为什么会发生这种情况？

我不用域名，直接用 IP 就行。我知道我可以从很多不同的 DNS 主机那里获得免费域名；我会真的宁愿不。

网络设置

我有一台路由器连接到一台物理服务器，该服务器是 Caddy 和两个 Web 应用程序的所在地。我将端口 443 从路由器转发到安装 Caddy 的服务器。

curl结果

192.168.1.5是我的内部 IP。203.0.113.0表示我的外部 IP（感谢 @Nikita Kipriyanov 指出RFC1918和RFC5737）。

看起来两个请求至少都到达了 Caddy（基于 HTTP/2 200 行），但我不明白为什么当请求来自外部 IP 时它什么都不返回。这两个请求都不会在 Caddy 终端输出中产生任何错误。

就像我之前提到的，我没有使用域名，只是直接使用 IP。我不确定这是否与我遇到的问题有关，但在我看来这应该无关紧要；我已经告诉过使用curl该选项忽略有关不受信任证书的警告-k。

使用内网IP时的输出

admin@server:~$ curl -vk https://192.168.1.5/
*   Trying 192.168.1.5:443...
* TCP_NODELAY set
* Connected to 192.168.1.5 (192.168.1.5) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: [NONE]
*  start date: Aug 21 00:46:28 2022 GMT
*  expire date: Aug 21 12:46:28 2022 GMT
*  issuer: CN=Caddy Local Authority - ECC Intermediate
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x561a91115210)
> GET / HTTP/2
> Host: 192.168.1.5
> user-agent: curl/7.68.0
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 200 
< content-type: text/html; charset=utf-8
< cross-origin-opener-policy: same-origin
< referrer-policy: same-origin
< server: Caddy
< x-content-type-options: nosniff
< x-frame-options: DENY
< content-length: 2921
< date: Sun, 21 Aug 2022 05:07:17 GMT
 
<!doctype html>
<html lang="en">
  <body>
    <h1>Hello World!</h1>
  </body>
</html>
* Connection #0 to host 192.168.1.5 left intact

使用外部IP时的输出

admin@server:~$ curl -vk https://203.0.113.0/
*   Trying 203.0.113.0:443...
* TCP_NODELAY set
* Connected to 203.0.113.0 (203.0.113.0) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: [NONE]
*  start date: Aug 21 00:46:28 2022 GMT
*  expire date: Aug 21 12:46:28 2022 GMT
*  issuer: CN=Caddy Local Authority - ECC Intermediate
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e3ae7aa210)
> GET / HTTP/2
> Host: 203.0.113.0
> user-agent: curl/7.68.0
> accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 200 
< server: Caddy
< content-length: 0
< date: Sun, 21 Aug 2022 05:08:16 GMT
< 
* Connection #0 to host 203.0.113.0 left intact

Caddy文件

192.168.1.5是我的内部IP。

我知道 app-one 有两个句柄；存在一个配置问题，即 app-one 删除尾随/并重定向，然后导致 app-two（带有 catch-all 句柄的那个）匹配，因此修复方法是为这种情况创建第二个句柄。我非常确信这不是问题所在。

{
        default_sni 192.168.1.5
}

https://192.168.1.5:443 {
        handle /file-server/* {
                root * /var/
                file_server browse
        }

        handle /app-one/* {
                reverse_proxy /app-one/* localhost:30000
        }

        handle /app-one {
                reverse_proxy /app-one localhost:30000
        }

        handle {
                reverse_proxy * localhost:8000
        }
}

答案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 服务器。使用名称。

答案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
        }
}

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

  1. 从路由器转发的请求不会将 Host 标头更改为内部 IP 地址；它只是将整个请求转发到内部 IP 地址。因此，https://192.168.1.5Caddy 收到的不是路由的请求，而是路由的请求https://203.0.113.0。由于没有路由https://203.0.113.0，它只是发回了一个空白页。
  2. 路由器配置为监听端口: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>

相关内容