根据MarcoPivetta的建议，我多年来一直使用Caddy作为前端反向代理。版本2发布的某个时候，我在某个时候进行了更新，但显然没有完全了解它的一些配置选项，特别是围绕HSTS支持并提供有关客户端如何尝试连接的代理应用程序信息。
Caddy一直有一个相当明确的语法，并倾向于合理的默认值。语法就像YAML和HCL的混合体，无论好坏，它包括用于替换请求或块特定值的占位符。幸运的是，你无需编写太多内容即可使最常见的场景正常工作。v2现在也提供了JSON语法。JSON语法提供了对所有配置选项的完全访问权限，如果您希望能够，学习该语法特别有用通过Caddy2的配置API动态更新配置。也就是说，JSON语法非常冗长，并且有相当多的嵌套成员；我发现在我的大部分使用中，声明式HCL语法往往更易于阅读和实现。
例如，为在另一台机器的端口9000上运行的服务创建反向代理的记录方法很简单，默认情况下使用HTTPS：
your.host.name {
reverse_proxy machine-running-actual-service:9000
}
砰，完成。
更好的是：Caddy还可以通过HTTPS提供本地IP和地址。它将使用自己的根证书生成自签名证书，然后您可以将其安装到系统信任库中。好处您是否可以使用TLS在本地测试您的网站，这有助于测试JavaScript交互，并减少与生产环境的行为差异。
保护反向代理
也就是说，我在运行反向代理时遇到了一些小问题：
- 我假设HSTS标头已到位。但事实并非如此。（不过，这适用于任何Caddy服务的站点，并不特定于反向代理。）
- 我假设诸如
X-Forwarded-Host和X-Real-IP请求标头已到位。它们不是。也就是说：默认情况下，Caddy:- 将
Host标头原封不动地传递给代理。这实际上非常方便，因为大多数应用程序框架无论如何都会更喜欢Host标头。 - 添加
X-Forwarded-Proto标头；这是其他网络服务器和网络应用程序框架最常使用的标准。 - 添加或更新负载平衡器使用的
X-Forwarded-For标头。
li>
- 将
幸运的是，为这些添加配置相对简单
your.host.name {
reverse_proxy machine-running-actual-service:9000 {
header_up X-Real-IP {remote}
header_down Strict-Transport-Security max-age=31536000
}
}
如果你有相当多的反向代理，你可能不想复制粘贴那些。Caddy再次来救援：配置支持片段。这些看起来像你的主机块，但是名称将在括号中。当配置块可以重新使用它时，它可以按名称导入它。
(reverseproxyheaders) {
header_up X-Real-IP {remote}
header_down Strict-Transport-Security max-age=31536000
}
your.host.name {
reverse_proxy machine-running-actual-service:9000 {
import reverseproxyheaders
}
}
通过这些更改，我的应用程序现在：
- 可以正确解析客户端IP
- 向客户端提供HSTSheaders，帮助保护用户免受MITM攻击
我自己的配置定义了三个反向代理，两个重定向到别处的子域，定义了一个静态站点，总共34行配置。
我会的。
尾注
为什么要使用Caddy，特别是如果您熟悉和/或熟悉Apache或nginx？
对我来说，决定归结为合理的默认设置和易于设置。使用Apache或nginx设置ACME，虽然它变得更简单，但不是交钥匙的。然而，Caddy默认采用TLS，使用ACME来编组TLS证书，并将非TLS请求重定向到TLS，所有这些都不需要任何额外的配置。同样，设置反向代理通常可以像将其指向代理一样简单，并且不需要记住通过在通用标头上，将其与传统Web服务器区分开来。最后，它是为提高速度而构建的，而且我发现将其作为反向代理运行的性能开销基本上可以忽略不计。
我发现它对我的目的很有用，并且在使用基于Docker的部署时特别方便，因为它在其他容器前面作为反向代理运行良好。显然，您的里程可能会有所不同。
