The solution you want
Hello, as I don't understand chinese, could someone explain the status of this pull request ? It seems that it solves my issue
https://github.com/fatedier/frp/pull/1919
As Caddy Server provides wss support out-of-the-box (I didn't need any configuration on this), I would need ro reverse proxy https + wss with FRP. For now, wss are in 'pending' mode in Chrome.
Alternatives considered
I don't think there is any alternative, but please explain how to configure rpc for this !
Thanks !
It won't be supported since the protocol is between frpc and frps.
What's your usage scenario?
Dear,
I was using Caddy server to handle http/https requests, but it exposes the public IP of my home router. I would like to hide my public IP by tunneling thanks to FRP.
I would like to expose a Node-Red instance through FRP, but the wss flow stays in "pending" status.
As explained here, node-red needs wss://domain.ltd/comms to push real-time debug messages to the webinterface:

As wss is quiet popular protocol now, I guess it would interest lots of FRP users :)
It works out-of-the-box with Caddyfile with this config:
nodered.mydomain.com {
log {
output file /logs/nodered.log
}
reverse_proxy localhost:1880
}
Do you need more clarification from my side ?
Thanks, best !
You can find more solutions from these documents:
https://github.com/fatedier/frp#visit-your-web-service-in-lan-by-custom-domains
https://github.com/fatedier/frp#enable-https-for-local-http-service
Or just use TCP type https://github.com/fatedier/frp#access-your-computer-in-lan-by-ssh
Hi @fatedier, our frps is behind a https load balancer which forces http to https, so we can't use insecure websocket connection. The proposed change is simple and it works (could it be refined?, maybe, I don't know), but it would be super useful to have the feature out of the box instead of having to merge the code ourself.
@fewkso You problem isn't same here.
It's not the protocol we want to support between frpc and frps. It will limit the future design for frp's self protocol.
You can try to combine frps with other tunnel projects which can tunnel TCP on other protocols like websocket or UDP.
Hello, I digg into this issue and found that websocket are working properly in http mode:
[nodered-http]
type = http
local_ip = my-server-ip
local_port = 1880
custom_domains = nodered.mydomain.com

but when I switch to https, the websocket protocol switch from _ws://nodered.mydomain.com/comms_ to _wss://nodered.mydomain.com/comms_
and status is endless '_pending_' as described at the beginning of this ticket.
[nodered-https]
type = https
custom_domains = nodered.mydomain.com
plugin = https2http
plugin_local_addr = my-server-ip:1880
plugin_crt_path = /etc/fullchain.pem
plugin_key_path = /etc/privkey.pem
plugin_host_header_rewrite = my-server-ip:1880
Do you have any idea how to proxy wss protocol thanks to FRP ?
Thanks ! all the best !
I encounter the same problem when using https2http plugin, when the backend is not nginx. I think it might because the backend does not provide as much information as nginx to the frp for it's normally functioning. As suggested by #2125, you could use nginx as an intermediate server to do the http to https convert, like backend <---http---> nginx <---https---> frp.
a websocket bug fixed by #2199 , now you can try new release v0.35.0
wss will be supported later.
Hello, I digg into this issue and found that websocket are working properly in http mode:
[nodered-http] type = http local_ip = my-server-ip local_port = 1880 custom_domains = nodered.mydomain.com
but when I switch to https, the websocket protocol switch from _ws://nodered.mydomain.com/comms_ to _wss://nodered.mydomain.com/comms_
and status is endless '_pending_' as described at the beginning of this ticket.
[nodered-https] type = https custom_domains = nodered.mydomain.com plugin = https2http plugin_local_addr = my-server-ip:1880 plugin_crt_path = /etc/fullchain.pem plugin_key_path = /etc/privkey.pem plugin_host_header_rewrite = my-server-ip:1880Do you have any idea how to proxy wss protocol thanks to FRP ?
Thanks ! all the best !
I test it in the lastest dev branch and it seems that the problem persists.
I created a test case to reproduce this issue. It seems that it's a different issue from the KeepAlive one, because in the test case, all the requests is simulated in the tcp layer.
# Ubuntu 20.04
tar zxf wss_test.tar.gz
cd wss_test
frps -c frps.ini &
frpc -c frpc.ini &
In another shell
python3 wss_test.py
# The read operation timed out when client accepting handshaking message
Some explanation can be seen in wss_test.py.