【问题标题】:HTTPS proxy with caddy带有 caddy 的 HTTPS 代理
【发布时间】:2017-12-31 15:55:59
【问题描述】:

我正在使用 Golang 应用程序和 Caddy 作为 HTTP 服务器。 golang 应用程序拒绝每个 http 连接,它只能通过 HTTPS 使用。此应用程序是一种由其他应用程序使用的 API/服务。因为,它需要 HTTPS 我安装了 Caddy,所以我可以利用自动 SSL 证书并使用代理在端口之间切换。

应用程序在端口 9000 中运行,因此,消费者只会写入 mysite.com,并且 caddy 应该负责将请求重定向到端口 9000 但维护 HTTPS。该站点的caddy中的配置是:

mysite.com {
    proxy / :9000 {
        max_fails 1
    }
    log logfile
}

尽管如此,似乎在制作代理时 HTTPS 丢失了。我检查了应用程序的日志(没有球童的日志),我得到了这个:

http: TLS handshake error from xxx.xxx.xxx.xxx:xxxx: tls: oversized record received with length 21536

因此,基于此错误,在我看来,caddy 制作的 HTTP 代理正在丢失 HTTPS。我能做什么?

【问题讨论】:

  • 要明确的是端口9000监听http还是https?
  • 如果是听https,你应该试试proxy / https://localhost:9000
  • @captncraig HTTPS。谢谢!

标签: ssl go tls1.2 caddy


【解决方案1】:

来自caddy docs

to 是要代理到的目标端点。至少需要一个, 但可以指定多个。如果方案 (http/https) 不是 指定,使用http。 Unix 套接字也可以通过前缀来使用 “unix:”。

所以它可能正在向代理的 https 端点发送 http 请求。

mysite.com {
    proxy / https://localhost:9000 {
        max_fails 1
    }
    log logfile
}

修复它?

如果是这种情况,您可能并不严格要求您的应用在 :9000 上收听 https。它可以简化您的部署或证书管理,只需让它侦听 http 并让 caddy 管理所有证书。

【讨论】:

  • 或者摆脱 caddy,因为您只是使用 Go http 服务器来代理 Go http 服务器,这对您没有任何好处。
  • @Adrian 大概他喜欢球童的 Let's Encrypt 集成。这可以在他自己的代码中以其他方式获得,但球童很容易投入。
  • autocert 也是如此,另外,OP 已经从他们自己的应用程序中公开了 HTTPS,这就是所陈述的问题(当应用程序需要 HTTPS 时,Caddy 正在发送 HTTP 流量),这意味着他们已经必须处理证书。在给定的场景中,Caddy 添加零值。
  • 或者OP可以embed Caddy
猜你喜欢
  • 2022-12-14
  • 2018-12-29
  • 1970-01-01
  • 2020-03-26
  • 1970-01-01
  • 1970-01-01
  • 2021-05-09
  • 2016-01-20
  • 2019-08-27
相关资源
最近更新 更多