[GH-ISSUE #4121] 关于HTTPS #3251

Closed
opened 2026-05-05 14:05:54 -06:00 by gitea-mirror · 5 comments
Owner

Originally created by @jinghuashang on GitHub (Apr 2, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4121

Bug Description

服务器端设置了https端口,但是代理的时候NGINX报错502 Bad Gateway,根据经验是代理端口并没有被代理东西,但是防火墙配置显示https端口已经使用

frpc Version

0.56

frps Version

0.56

System Architecture

linux/amd64

Configurations

[frps]
vhostHTTPPort = 8880
vhostHTTPSPort = 8443
[frpc]
proxies
name = "HTTPS"
type = "https"
localPort = 8091
localIP = "127.0.0.1"
transport.proxyProtocolVersion = "v2"
customDomains = ["vd.******cn"]

Logs

No response

Steps to reproduce

...

Affected area

  • Docs
  • Installation
  • Performance and Scalability
  • Security
  • User Experience
  • Test and Release
  • Developer Infrastructure
  • Client Plugin
  • Server Plugin
  • Extensions
  • Others
Originally created by @jinghuashang on GitHub (Apr 2, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/4121 ### Bug Description 服务器端设置了https端口,但是代理的时候NGINX报错502 Bad Gateway,根据经验是代理端口并没有被代理东西,但是防火墙配置显示https端口已经使用 ### frpc Version 0.56 ### frps Version 0.56 ### System Architecture linux/amd64 ### Configurations [frps] vhostHTTPPort = 8880 vhostHTTPSPort = 8443 [frpc] [[proxies]] name = "HTTPS" type = "https" localPort = 8091 localIP = "127.0.0.1" transport.proxyProtocolVersion = "v2" customDomains = ["vd.******cn"] ### Logs _No response_ ### Steps to reproduce 1. 2. 3. ... ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others
Author
Owner

@peace4j commented on GitHub (Apr 10, 2024):

如果都已经能看到nginx返回的502,说明至少这个转发是通了的。但是估计是转发设置错误的缘故,导致请求的url及http头,或者证书错误等缘故,让nginx返回了502

这种情况可以逐步排除各种可能的错误设置。
首先可以先试下不配置https,只配置http的时候是否成功。
另外,transport.proxyProtocolVersion = "v2"这个设置也可以先去掉试试。毕竟它不影响转发。

<!-- gh-comment-id:2047431423 --> @peace4j commented on GitHub (Apr 10, 2024): 如果都已经能看到nginx返回的502,说明至少这个转发是通了的。但是估计是转发设置错误的缘故,导致请求的url及http头,或者证书错误等缘故,让nginx返回了502 这种情况可以逐步排除各种可能的错误设置。 首先可以先试下不配置https,只配置http的时候是否成功。 另外,transport.proxyProtocolVersion = "v2"这个设置也可以先去掉试试。毕竟它不影响转发。
Author
Owner

@jinghuashang commented on GitHub (Apr 10, 2024):

如果都已经能看到nginx返回的502,说明至少这个转发是通了的。但是估计是转发设置错误的缘故,导致请求的url及http头,或者证书错误等缘故,让nginx返回了502

这种情况可以逐步排除各种可能的错误设置。 首先可以先试下不配置https,只配置http的时候是否成功。 另外,transport.proxyProtocolVersion = “v2”这个设置也可以先去掉试试。毕竟它不影响转发。

根据排除和frpc配置无关,正常代理
正常代理为图片显示,但是通过反代访问配置的https端口后为 502 Bad Gateway

<!-- gh-comment-id:2047448182 --> @jinghuashang commented on GitHub (Apr 10, 2024): > 如果都已经能看到nginx返回的502,说明至少这个转发是通了的。但是估计是转发设置错误的缘故,导致请求的url及http头,或者证书错误等缘故,让nginx返回了502 > > 这种情况可以逐步排除各种可能的错误设置。 首先可以先试下不配置https,只配置http的时候是否成功。 另外,transport.proxyProtocolVersion = “v2”这个设置也可以先去掉试试。毕竟它不影响转发。 根据排除和frpc配置无关,![正常代理](https://github.com/fatedier/frp/assets/77230776/cfa03007-eba0-41d6-ba3a-f691d957f36d) 正常代理为图片显示,但是通过反代访问配置的https端口后为 `502 Bad Gateway`
Author
Owner

@peace4j commented on GitHub (Apr 11, 2024):

如果都已经能看到nginx返回的502,说明至少这个转发是通了的。但是估计是转发设置错误的缘故,导致请求的url及http头,或者证书错误等缘故,让nginx返回了502
这种情况可以逐步排除各种可能的错误设置。 首先可以先试下不配置https,只配置http的时候是否成功。 另外,transport.proxyProtocolVersion = “v2”这个设置也可以先去掉试试。毕竟它不影响转发。

根据排除和frpc配置无关,正常代理 正常代理为图片显示,但是通过反代访问配置的https端口后为 502 Bad Gateway

如果你看到的是nginx的502,而不是你图示的frp的提示,更说明从浏览器到frps到frpc到nginx这一条路已经通顺,转发已经生效。只是nginx收到的request的格式(可能包括了url、http包头、tls加密、proxy protocol等)与nginx期望的不一致(因为经过了多层转发,http包头已经被改了),所以它无法正确处理,于是返回了502。
我在一个在docker上使用caddy转发特定域名的http到frps端口,然后转发到frpc指定的内网http服务的配置测试中就碰到过,在配置中设置proxy protocol(不论是v1还是v2)都会出错(从http服务response的内容就能看到错误内容有区别,但访问端提交的请求其实一模一样),但是取消proxy protocol就OK的情况。

所以建议你先简化配置,在正确通过后再逐步加料,基本能迅速确定是哪个环节的问题。

<!-- gh-comment-id:2048720401 --> @peace4j commented on GitHub (Apr 11, 2024): > > 如果都已经能看到nginx返回的502,说明至少这个转发是通了的。但是估计是转发设置错误的缘故,导致请求的url及http头,或者证书错误等缘故,让nginx返回了502 > > 这种情况可以逐步排除各种可能的错误设置。 首先可以先试下不配置https,只配置http的时候是否成功。 另外,transport.proxyProtocolVersion = “v2”这个设置也可以先去掉试试。毕竟它不影响转发。 > > 根据排除和frpc配置无关,![正常代理](https://private-user-images.githubusercontent.com/77230776/321241385-cfa03007-eba0-41d6-ba3a-f691d957f36d.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTI3OTcyOTgsIm5iZiI6MTcxMjc5Njk5OCwicGF0aCI6Ii83NzIzMDc3Ni8zMjEyNDEzODUtY2ZhMDMwMDctZWJhMC00MWQ2LWJhM2EtZjY5MWQ5NTdmMzZkLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MTElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDExVDAwNTYzOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTA2NjFmM2YxNjA3ZmYxODUzZDg1MzBjYmQyOWE0ZjljZmRmZGIwYzRjYWFiZjJlODdhMDBkYzE4NTEyYThlYWQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.bb3237ShQSq6UBuxSZqd9wCkGghKvGTMdEiK_j5Jbu0) 正常代理为图片显示,但是通过反代访问配置的https端口后为 `502 Bad Gateway` 如果你看到的是nginx的502,而不是你图示的frp的提示,更说明从浏览器到frps到frpc到nginx这一条路已经通顺,转发已经生效。只是nginx收到的request的格式(可能包括了url、http包头、tls加密、proxy protocol等)与nginx期望的不一致(因为经过了多层转发,http包头已经被改了),所以它无法正确处理,于是返回了502。 我在一个在docker上使用caddy转发特定域名的http到frps端口,然后转发到frpc指定的内网http服务的配置测试中就碰到过,在配置中设置proxy protocol(不论是v1还是v2)都会出错(从http服务response的内容就能看到错误内容有区别,但访问端提交的请求其实一模一样),但是取消proxy protocol就OK的情况。 所以建议你先简化配置,在正确通过后再逐步加料,基本能迅速确定是哪个环节的问题。
Author
Owner

@jinghuashang commented on GitHub (Apr 25, 2024):

如果都已经能看到nginx返回的502,说明至少这个转发是通了的。但是估计是转发设置错误的缘故,导致请求的url及http头,或者证书错误等缘故,让nginx返回了502
这种情况可以逐步排除各种可能的错误设置。 首先可以先试下不配置https,只配置http的时候是否成功。 另外,transport.proxyProtocolVersion = “v2”这个设置也可以先去掉试试。毕竟它不影响转发。

根据排除和frpc配置无关,正常代理 正常代理为图片显示,但是通过反代访问配置的https端口后为 502 Bad Gateway

如果你看到的是nginx的502,而不是你图示的frp的提示,更说明从浏览器到frps到frpc到nginx这一条路已经通顺,转发已经生效。只是nginx收到的request的格式(可能包括了url、http包头、tls加密、proxy protocol等)与nginx期望的不一致(因为经过了多层转发,http包头已经被改了),所以它无法正确处理,于是返回了502。 我在一个在docker上使用caddy转发特定域名的http到frps端口,然后转发到frpc指定的内网http服务的配置测试中就碰到过,在配置中设置proxy protocol(不论是v1还是v2)都会出错(从http服务response的内容就能看到错误内容有区别,但访问端提交的请求其实一模一样),但是取消proxy protocol就OK的情况。

所以建议你先简化配置,在正确通过后再逐步加料,基本能迅速确定是哪个环节的问题。

不,你可能没有理解我的意思,我将https设置为8443端口,在防火墙已显示被使用。但是经过反代并没被部署到8443,而反代端口无数据才会显示为 502 Bad Gateway ,这说明https并没有正常工作,而这个不正常与 proxy protocol 无关,因为删掉或新建一个还是存在这种问题。

<!-- gh-comment-id:2076863233 --> @jinghuashang commented on GitHub (Apr 25, 2024): > > > 如果都已经能看到nginx返回的502,说明至少这个转发是通了的。但是估计是转发设置错误的缘故,导致请求的url及http头,或者证书错误等缘故,让nginx返回了502 > > > 这种情况可以逐步排除各种可能的错误设置。 首先可以先试下不配置https,只配置http的时候是否成功。 另外,transport.proxyProtocolVersion = “v2”这个设置也可以先去掉试试。毕竟它不影响转发。 > > > > > > 根据排除和frpc配置无关,![正常代理](https://private-user-images.githubusercontent.com/77230776/321241385-cfa03007-eba0-41d6-ba3a-f691d957f36d.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTI3OTcyOTgsIm5iZiI6MTcxMjc5Njk5OCwicGF0aCI6Ii83NzIzMDc3Ni8zMjEyNDEzODUtY2ZhMDMwMDctZWJhMC00MWQ2LWJhM2EtZjY5MWQ5NTdmMzZkLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MTElMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDExVDAwNTYzOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTA2NjFmM2YxNjA3ZmYxODUzZDg1MzBjYmQyOWE0ZjljZmRmZGIwYzRjYWFiZjJlODdhMDBkYzE4NTEyYThlYWQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.bb3237ShQSq6UBuxSZqd9wCkGghKvGTMdEiK_j5Jbu0) 正常代理为图片显示,但是通过反代访问配置的https端口后为 `502 Bad Gateway` > > 如果你看到的是nginx的502,而不是你图示的frp的提示,更说明从浏览器到frps到frpc到nginx这一条路已经通顺,转发已经生效。只是nginx收到的request的格式(可能包括了url、http包头、tls加密、proxy protocol等)与nginx期望的不一致(因为经过了多层转发,http包头已经被改了),所以它无法正确处理,于是返回了502。 我在一个在docker上使用caddy转发特定域名的http到frps端口,然后转发到frpc指定的内网http服务的配置测试中就碰到过,在配置中设置proxy protocol(不论是v1还是v2)都会出错(从http服务response的内容就能看到错误内容有区别,但访问端提交的请求其实一模一样),但是取消proxy protocol就OK的情况。 > > 所以建议你先简化配置,在正确通过后再逐步加料,基本能迅速确定是哪个环节的问题。 不,你可能没有理解我的意思,我将https设置为8443端口,在防火墙已显示被使用。但是经过反代并没被部署到8443,而反代端口无数据才会显示为 `502 Bad Gateway` ,这说明https并没有正常工作,而这个不正常与 `proxy protocol` 无关,因为删掉或新建一个还是存在这种问题。
Author
Owner

@ks4na commented on GitHub (May 24, 2024):

@jinghuashang 你的问题是这个吗?

<!-- gh-comment-id:2128518049 --> @ks4na commented on GitHub (May 24, 2024): @jinghuashang 你的问题是这个吗? - #4239
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#3251
No description provided.