[GH-ISSUE #2194] 是否考虑增加wss支持

gitea-mirror commented

2026-05-05 13:07:25 -06:00

Owner

Originally created by @ndj888 on GitHub (Jan 16, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2194

现状
frp支持了 tcp、udp、kcp甚至是ws，但唯独没有支持安全的websocket wss。

弊端
由于大部分frps服务部署在vps实例上，所需应用层协议都可以通过4层tcp协议实现穿透。

k8s 集群中使用困惑
场景：aws eks中部署，多使用k8s ingress 共用一个负载均衡elb。ingress 仅支持 80、443端口，若需要使用tcp 则需要配置 NodePort 并增加一个elb ，这将增加服务费用。
困惑2：我使用frp 支持的 ws 成功完成了部署，在k8s 上配置一个域名使用http80端口作为远程服务端口，客户端使用websocket建立通信；这一切工作正常。当我给服务端配置好tls证书后，情况开始糟糕，由于服务端使用了ssl证书，客户端建立ws通信会一直得到 bad request . 所以我希望客户端支持wss协议!看到几个pr 增加了 wss协议，但迟迟没有得到合并。。。。

Originally created by @ndj888 on GitHub (Jan 16, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2194 **现状** frp支持了 tcp、udp、kcp甚至是ws，但唯独没有支持安全的websocket wss。 **弊端** _由于大部分frps服务部署在vps实例上，所需应用层协议都可以通过4层tcp协议实现穿透。_ **k8s 集群中使用困惑** 场景：aws eks中部署，多使用k8s ingress 共用一个负载均衡elb。ingress 仅支持 80、443端口，若需要使用tcp 则需要配置 NodePort 并增加一个elb ，这将增加服务费用。困惑2：我使用frp 支持的 ws 成功完成了部署，在k8s 上配置一个域名使用http80端口作为远程服务端口，客户端使用websocket建立通信；这一切工作正常。当我给服务端配置好tls证书后，情况开始糟糕，由于服务端使用了ssl证书，客户端建立ws通信会一直得到 bad request . 所以我希望客户端支持wss协议!看到几个pr 增加了 wss协议，但迟迟没有得到合并。。。。

gitea-mirror

2026-05-05 13:07:25 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:07:29 -06:00

Author

Owner

@fatedier commented on GitHub (Jan 17, 2021):

先理解一个概念，frp 支持 TCP, UDP, HTTP/HTTPS 等协议的内网穿透。

frpc 和 frps 之间的通信协议支持 TCP，KCP，Websocket。

WSS 基于 HTTPS，所以支持 WSS 的内网穿透。

frp 的内部通信协议，目前主要支持 TCP(标准)，KCP(解决弱网环境下的传输问题)，这两个都是传输层的协议。WSS 和 Websocket 的原理类似，都是应用层的协议，和 frp 自身无关，只是将本来的协议封装在一个外壳中传输，更适合单独作为一个工具来使用，这一点在之前的 issue 里也提过。

所以我个人是不希望在 frpc 和 frps 之间的通信里引入过多的应用层协议，会增加不必要的维护成本。

你上述的场景也确实存在，是否可以理解为你希望通过一个使用 WSS 协议的代理来访问处于代理后的 frps？

@fatedier commented on GitHub (Jan 17, 2021): 先理解一个概念，frp 支持 TCP, UDP, HTTP/HTTPS 等协议的内网穿透。 frpc 和 frps 之间的通信协议支持 TCP，KCP，Websocket。 WSS 基于 HTTPS，所以支持 WSS 的内网穿透。 frp 的内部通信协议，目前主要支持 TCP(标准)，KCP(解决弱网环境下的传输问题)，这两个都是传输层的协议。WSS 和 Websocket 的原理类似，都是应用层的协议，和 frp 自身无关，只是将本来的协议封装在一个外壳中传输，更适合单独作为一个工具来使用，这一点在之前的 issue 里也提过。所以我个人是不希望在 frpc 和 frps 之间的通信里引入过多的应用层协议，会增加不必要的维护成本。你上述的场景也确实存在，是否可以理解为你希望通过一个使用 `WSS` 协议的代理来访问处于代理后的 frps？

gitea-mirror commented

2026-05-05 13:07:30 -06:00

Author

Owner

@ndj888 commented on GitHub (Jan 17, 2021):

是的，我希望使用wss协议作为frpc 和frps通信。因为在k8s集群上部署使用，使用原生tcp协议，意味着需要增加一个elb 并绑定一个公网ip，这确实增加了费用。

@ndj888 commented on GitHub (Jan 17, 2021): 是的，我希望使用wss协议作为frpc 和frps通信。因为在k8s集群上部署使用，使用原生tcp协议，意味着需要增加一个elb 并绑定一个公网ip，这确实增加了费用。

gitea-mirror commented

2026-05-05 13:07:30 -06:00

Author

Owner

@ndj888 commented on GitHub (Jan 18, 2021):

我使用了这个pr构建frpc，工作正常。目前看起来没有问题，希望官方进一步审查，早日合并到主干。
1919
@fatedier

@ndj888 commented on GitHub (Jan 18, 2021): 我使用了这个pr构建frpc，工作正常。目前看起来没有问题，希望官方进一步审查，早日合并到主干。 [1919](https://github.com/fatedier/frp/pull/1919) @fatedier

gitea-mirror commented

2026-05-05 13:07:31 -06:00

Author

Owner

@babyzhang commented on GitHub (Jan 19, 2021):

关注

@babyzhang commented on GitHub (Jan 19, 2021): 关注

gitea-mirror commented

2026-05-05 13:07:31 -06:00

Author

Owner

@yuyulei commented on GitHub (Feb 3, 2021):

是的，我希望使用wss协议作为frpc 和frps通信。因为在k8s集群上部署使用，使用原生tcp协议，意味着需要增加一个elb 并绑定一个公网ip，这确实增加了费用。

你是希望一个代理支持支持，client -> (wss) -> frps -> (X) -> frpc ->(wss) -> app，中间的 X 是可以看做是frp 内部“传输层“的协议，目前有 TCP 和 KCP，这个对上层应用层协议是透明的。

你可以再理一理，看看是不是这么回事。

@yuyulei commented on GitHub (Feb 3, 2021): > 是的，我希望使用wss协议作为frpc 和frps通信。因为在k8s集群上部署使用，使用原生tcp协议，意味着需要增加一个elb 并绑定一个公网ip，这确实增加了费用。你是希望一个代理支持支持，client -> (wss) -> frps -> (X) -> frpc ->(wss) -> app，中间的 X 是可以看做是frp 内部“传输层“的协议，目前有 TCP 和 KCP，这个对上层应用层协议是透明的。你可以再理一理，看看是不是这么回事。

gitea-mirror commented

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

Author

Owner

@ndj888 commented on GitHub (Feb 3, 2021):

是的，我希望使用wss协议作为frpc 和frps通信。因为在k8s集群上部署使用，使用原生tcp协议，意味着需要增加一个elb 并绑定一个公网ip，这确实增加了费用。

你是希望一个代理支持支持，client -> (wss) -> frps -> (X) -> frpc ->(wss) -> app，中间的 X 是可以看做是frp 内部“传输层“的协议，目前有 TCP 和 KCP，这个对上层应用层协议是透明的。

你可以再理一理，看看是不是这么回事。

是的，我希望支持，这让我更方便

@ndj888 commented on GitHub (Feb 3, 2021): > > 是的，我希望使用wss协议作为frpc 和frps通信。因为在k8s集群上部署使用，使用原生tcp协议，意味着需要增加一个elb 并绑定一个公网ip，这确实增加了费用。 > > 你是希望一个代理支持支持，client -> (wss) -> frps -> (X) -> frpc ->(wss) -> app，中间的 X 是可以看做是frp 内部“传输层“的协议，目前有 TCP 和 KCP，这个对上层应用层协议是透明的。 > > 你可以再理一理，看看是不是这么回事。是的，我希望支持，这让我更方便

gitea-mirror commented

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

Author

Owner

@badgv commented on GitHub (Feb 3, 2021):

之前就有人提起过这个建议了，别人提交的代码，也是可用的，只是没合并，并且合并请求已经被关闭了
支持WSS能提升frps和frpc之间连接的安全性级别（https），并且可用nginx或apache2之类的WEB服务器进行反代连接，实现端口复用。
用别人合并了wss代码的fork编译了个支持wss的docker镜像：https://hub.docker.com/r/badgv/frp
有需要可以先用着，目前用着没其它问题

@badgv commented on GitHub (Feb 3, 2021): 之前就有人提起过这个建议了，别人提交的代码，也是可用的，只是没合并，并且合并请求已经被关闭了支持WSS能提升frps和frpc之间连接的安全性级别（https），并且可用nginx或apache2之类的WEB服务器进行反代连接，实现端口复用。用别人合并了wss代码的fork编译了个支持wss的docker镜像：https://hub.docker.com/r/badgv/frp 有需要可以先用着，目前用着没其它问题

gitea-mirror commented

2026-05-05 13:07:34 -06:00

Author

Owner

@marcusptc commented on GitHub (Feb 14, 2021):

是的，我希望使用wss协议作为frpc 和frps通信。因为在k8s集群上部署使用，使用原生tcp协议，意味着需要增加一个elb 并绑定一个公网ip，这确实增加了费用。

你是希望一个代理支持支持，client -> (wss) -> frps -> (X) -> frpc ->(wss) -> app，中间的 X 是可以看做是frp 内部“传输层“的协议，目前有 TCP 和 KCP，这个对上层应用层协议是透明的。
你可以再理一理，看看是不是这么回事。

是的，我希望支持，这让我更方便

同意, WSS這個功能真的很有用.....

@marcusptc commented on GitHub (Feb 14, 2021): > > > 是的，我希望使用wss协议作为frpc 和frps通信。因为在k8s集群上部署使用，使用原生tcp协议，意味着需要增加一个elb 并绑定一个公网ip，这确实增加了费用。 > > > > > > 你是希望一个代理支持支持，client -> (wss) -> frps -> (X) -> frpc ->(wss) -> app，中间的 X 是可以看做是frp 内部“传输层“的协议，目前有 TCP 和 KCP，这个对上层应用层协议是透明的。 > > 你可以再理一理，看看是不是这么回事。 > > 是的，我希望支持，这让我更方便同意, WSS這個功能真的很有用.....

gitea-mirror commented

2026-05-05 13:07:34 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Apr 1, 2021):

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

@github-actions[bot] commented on GitHub (Apr 1, 2021): Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.

gitea-mirror commented

2026-05-05 13:07:34 -06:00

Author

Owner

@hyena04 commented on GitHub (Jun 11, 2021):

wss连接超时的问题，可以不可以解决一下。

@hyena04 commented on GitHub (Jun 11, 2021): wss连接超时的问题，可以不可以解决一下。

gitea-mirror commented

2026-05-05 13:07:35 -06:00

Author

Owner

@tudyzhb commented on GitHub (Oct 4, 2021):

在frp支持的协议中, Websocket与其他两种TCP, KCP显然不太一样, 比如ws和wss两种连接方式.

但是目前只支持domain:port的连接方式, 但只要稍加改动, 让server_addr参数支持URL格式，就可以优雅的支持wss了.

变动前用domain:port连接格式

frpc.ini:

[common]
server_addr = frps.server.host
server_port = 7007
token = SECRET
tls_enable = true
protocol = websocket

变动后额外支持URL连接格式

frpc.ini:

[common]
server_addr = wss://frps.server.host/frps/
token = SECRET
tls_enable = true
protocol = websocket

对应的nginx.conf片段:

...
# frps websocket proxy
location /frps/ {
    proxy_redirect off;
    proxy_pass http://127.0.0.1:7007/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    proxy_read_timeout 600s;
}
...

pull-2601整个wss支持的改动不超过20行代码,而且兼容以前的配置,希望这次能被合并.

@tudyzhb commented on GitHub (Oct 4, 2021): 在frp支持的协议中, Websocket与其他两种TCP, KCP显然不太一样, 比如ws和wss两种连接方式. 但是目前只支持`domain:port`的连接方式, 但只要稍加改动, 让`server_addr`参数支持`URL`格式，就可以优雅的支持wss了. - 变动前用`domain:port`连接格式 `frpc.ini`: ```frpc.ini [common] server_addr = frps.server.host server_port = 7007 token = SECRET tls_enable = true protocol = websocket ``` - 变动后额外支持`URL`连接格式 `frpc.ini`: ```frpc.ini [common] server_addr = wss://frps.server.host/frps/ token = SECRET tls_enable = true protocol = websocket ``` 对应的`nginx.conf`片段: ``` ... # frps websocket proxy location /frps/ { proxy_redirect off; proxy_pass http://127.0.0.1:7007/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_read_timeout 600s; } ... ``` [pull-2601](https://github.com/fatedier/frp/pull/2601)整个wss支持的改动不超过20行代码,而且兼容以前的配置,希望这次能被合并.

gitea-mirror commented

2026-05-05 13:07:35 -06:00

Author

Owner

@whwnow commented on GitHub (Dec 10, 2022):

在frp支持的协议中, Websocket与其他两种TCP, KCP显然不太一样, 比如ws和wss两种连接方式.

但是目前只支持domain:port的连接方式, 但只要稍加改动, 让server_addr参数支持URL格式，就可以优雅的支持wss了.

变动前用domain:port连接格式

frpc.ini:
[common]
server_addr = frps.server.host
server_port = 7007
token = SECRET
tls_enable = true
protocol = websocket
变动后额外支持URL连接格式

frpc.ini:
[common]
server_addr = wss://frps.server.host/frps/
token = SECRET
tls_enable = true
protocol = websocket
对应的nginx.conf片段:
...
# frps websocket proxy
location /frps/ {
    proxy_redirect off;
    proxy_pass http://127.0.0.1:7007/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    proxy_read_timeout 600s;
}
...
pull-2601整个wss支持的改动不超过20行代码,而且兼容以前的配置,希望这次能被合并.

兄弟可以再来一个 pull 了，看下这个https://github.com/fatedier/frp/issues/3162

@whwnow commented on GitHub (Dec 10, 2022): > 在frp支持的协议中, Websocket与其他两种TCP, KCP显然不太一样, 比如ws和wss两种连接方式. > > 但是目前只支持`domain:port`的连接方式, 但只要稍加改动, 让`server_addr`参数支持`URL`格式，就可以优雅的支持wss了. > > * 变动前用`domain:port`连接格式 > > `frpc.ini`: > > ```ini > [common] > server_addr = frps.server.host > server_port = 7007 > token = SECRET > tls_enable = true > protocol = websocket > ``` > > * 变动后额外支持`URL`连接格式 > > `frpc.ini`: > > ```ini > [common] > server_addr = wss://frps.server.host/frps/ > token = SECRET > tls_enable = true > protocol = websocket > ``` > > 对应的`nginx.conf`片段: > > ``` > ... > # frps websocket proxy > location /frps/ { > proxy_redirect off; > proxy_pass http://127.0.0.1:7007/; > proxy_http_version 1.1; > proxy_set_header Upgrade $http_upgrade; > proxy_set_header Connection "upgrade"; > proxy_set_header Host $http_host; > proxy_read_timeout 600s; > } > ... > ``` > > [pull-2601](https://github.com/fatedier/frp/pull/2601)整个wss支持的改动不超过20行代码,而且兼容以前的配置,希望这次能被合并. 兄弟可以再来一个 pull 了，看下这个https://github.com/fatedier/frp/issues/3162

Rows
Columns

[GH-ISSUE #2194] 是否考虑增加wss支持 #1747