[GH-ISSUE #2649] a problem when forword https and the domain is IP

gitea-mirror commented

2026-05-05 13:21:27 -06:00

Owner

Copy link

Originally created by @ZhiShengYuan on GitHub (Nov 9, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2649

Bug Description

when I try to use FRP(version 0.38.0) to forward IP SSL(like https://1.1.1.1), I meet a problem, that I can't use this IP to access SSL(but HTTP is normal), and use any domain which binds to this IP, I find the certificates is this IP, is anyone meet it too?
anyway,i enabled the proxy_protocol v2 and config correct in FRPC and Nginx,and the connection between server and client is normal,the connection of client and webserver too
by cap TCP package by tcpdump,it's seems that there is no any package send to the webserver at all
and there is no any new log science I try to access this(the log level already be trace)

frpc Version

0.38.0

frps Version

0.38.0

System Architecture

linux/amd64

Configurations

[common]
server_addr = SERVERIP
server_port = 7000
token = TOKEN
pool_count = 5
tcp_mux = true
protocol = tcp
tls_enable = true
tls_server_name = SERVER_SSL
udp_packet_size = 1500
disable_custom_tls_first_byte = true
[iphttpLocal]
type = http
local_ip = LocalServerIp
local_port = 80
use_encryption = true
use_compression = true
custom_domains = SERVERIP
header_X-From-Where = frp
[iphttpsLocal]
type = https
local_ip = LocalServerIp
local_port = 443
use_encryption = false
use_compression = false
custom_domains = SERVERIP
proxy_protocol_version = v2

Logs

2021/11/09 08:53:43 [I] [https.go:51] [160fff7092393c42] [iphttpsLocal] https proxy listen for host [IPSSL]
2021/11/09 08:53:43 [I] [control.go:444] [160fff7092393c42] new proxy [iphttpsLocal] success
2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered
2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered
2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered
2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered
2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered
2021/11/09 08:53:44 [T] [service.go:393] start check TLS connection...
2021/11/09 08:53:44 [T] [service.go:402] check TLS connection success, isTLS: true custom: false

Steps to reproduce

deploy frps in server and frpc in another device
2.config Nginx to accept proxy_protocol
config IP SSL for Nginx
4.use FRP to forward IP SSL

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @ZhiShengYuan on GitHub (Nov 9, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2649 ### Bug Description when I try to use FRP(version 0.38.0) to forward IP SSL(like https://1.1.1.1), I meet a problem, that I can't use this IP to access SSL(but HTTP is normal), and use any domain which binds to this IP, I find the certificates is this IP, is anyone meet it too? anyway,i enabled the proxy_protocol v2 and config correct in FRPC and Nginx,and the connection between server and client is normal,the connection of client and webserver too by cap TCP package by tcpdump,it's seems that there is no any package send to the webserver at all and there is no any new log science I try to access this(the log level already be trace) ### frpc Version 0.38.0 ### frps Version 0.38.0 ### System Architecture linux/amd64 ### Configurations [common] server_addr = SERVERIP server_port = 7000 token = TOKEN pool_count = 5 tcp_mux = true protocol = tcp tls_enable = true tls_server_name = SERVER_SSL udp_packet_size = 1500 disable_custom_tls_first_byte = true [iphttpLocal] type = http local_ip = LocalServerIp local_port = 80 use_encryption = true use_compression = true custom_domains = SERVERIP header_X-From-Where = frp [iphttpsLocal] type = https local_ip = LocalServerIp local_port = 443 use_encryption = false use_compression = false custom_domains = SERVERIP proxy_protocol_version = v2 ### Logs 2021/11/09 08:53:43 [I] [https.go:51] [160fff7092393c42] [iphttpsLocal] https proxy listen for host [IPSSL] 2021/11/09 08:53:43 [I] [control.go:444] [160fff7092393c42] new proxy [iphttpsLocal] success 2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered 2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered 2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered 2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered 2021/11/09 08:53:43 [D] [control.go:219] [160fff7092393c42] new work connection registered 2021/11/09 08:53:44 [T] [service.go:393] start check TLS connection... 2021/11/09 08:53:44 [T] [service.go:402] check TLS connection success, isTLS: true custom: false ### Steps to reproduce 1. deploy frps in server and frpc in another device 2.config Nginx to accept proxy_protocol 3. config IP SSL for Nginx 4.use FRP to forward IP SSL ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:21:27 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:21:32 -06:00

Author

Owner

Copy link

@ZhiShengYuan commented on GitHub (Nov 12, 2021):

so maybe is the problem of SSL host match?because i can got 301 by HTTP access(hsts enabled)

@ZhiShengYuan commented on GitHub (Nov 12, 2021): so maybe is the problem of SSL host match?because i can got 301 by HTTP access(hsts enabled)

gitea-mirror commented

2026-05-05 13:21:32 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Dec 13, 2021):

Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

@github-actions[bot] commented on GitHub (Dec 13, 2021): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.

No Branch/Tag specified