[GH-ISSUE #4558] [Feature Request] add support in frpc for demultiplexing (vhost) multiple HTTPS targets (based on SNI)

gitea-mirror commented

2026-05-05 14:18:53 -06:00

Owner

Originally created by @ofirc on GitHub (Nov 25, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/4558

Describe the feature request

Is there a way to implement SNI-based routing, that is to demultiplex a single connection onto different targets?

This is how I currently implement it with Caddy and Caddy L4 plugin:

{
   admin :2019
   debug
    layer4 {
        :4000 {
            @secure tls sni backend-a
            route @secure {
                proxy backend-a:6000
            }
            @secured tls sni backend-b
            route @secured {
                proxy backend-b:8000
            }
        }
    }
}

I put this in front of the backend servers and it allows to listen on a single port, 4000, and route it to the right backend by peeking at the SNI value.

I was wondering if there is an option to eliminate the Caddy reverse proxy altogether and implement it via the frpc.ini or frps.ini.

Thanks!

Describe alternatives you've considered

No response

Affected area

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

Originally created by @ofirc on GitHub (Nov 25, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/4558 ### Describe the feature request Is there a way to implement SNI-based routing, that is to demultiplex a single connection onto different targets? This is how I currently implement it with [Caddy](https://caddyserver.com/) and [Caddy L4 plugin](github.com/mholt/caddy-l4): ``` { admin :2019 debug layer4 { :4000 { @secure tls sni backend-a route @secure { proxy backend-a:6000 } @secured tls sni backend-b route @secured { proxy backend-b:8000 } } } } ``` I put this in front of the backend servers and it allows to listen on a single port, 4000, and route it to the right backend by peeking at the SNI value. I was wondering if there is an option to eliminate the Caddy reverse proxy altogether and implement it via the frpc.ini or frps.ini. Thanks! ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [X] Client Plugin - [ ] Server Plugin - [X] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:18:53 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:18:56 -06:00

Author

Owner

@fatedier commented on GitHub (Nov 26, 2024):

Currently, frp does not support SNI-based routing to demultiplex a single connection to different targets. However, this is a valuable suggestion, and we plan to consider it in future updates.

Thank you for sharing your use case!

@fatedier commented on GitHub (Nov 26, 2024): Currently, frp does not support SNI-based routing to demultiplex a single connection to different targets. However, this is a valuable suggestion, and we plan to consider it in future updates. Thank you for sharing your use case!

gitea-mirror commented

2026-05-05 14:18:57 -06:00

Author

Owner

@ofirc commented on GitHub (Dec 5, 2024):

Hi @fatedier thanks for the prompt response, appreciate that and will stay tuned!

@ofirc commented on GitHub (Dec 5, 2024): Hi @fatedier thanks for the prompt response, appreciate that and will stay tuned!

gitea-mirror commented

2026-05-05 14:18:57 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Dec 20, 2024):

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

@github-actions[bot] commented on GitHub (Dec 20, 2024): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

gitea-mirror commented

2026-05-05 14:18:58 -06:00

Author

Owner

@gregoiregentil commented on GitHub (Oct 14, 2025):

+1. I'm also interested to get such SNI-based feature. I do it in haproxy:

use_backend bckd if { req_ssl_sni -i a.example.com }
backend bckd
mode tcp
server frps IP:PORT_a

I don't need to do it for https as there is the option "vhostHTTPSPort".

Such implementation would be extremely valuable because it would allow to get rid of Caddy and/or HaProxy.

@gregoiregentil commented on GitHub (Oct 14, 2025): +1. I'm also interested to get such SNI-based feature. I do it in haproxy: use_backend bckd if { req_ssl_sni -i a.example.com } backend bckd mode tcp server frps IP:PORT_a I don't need to do it for https as there is the option "vhostHTTPSPort". Such implementation would be extremely valuable because it would allow to get rid of Caddy and/or HaProxy.

gitea-mirror commented

2026-05-05 14:18:58 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 15, 2025):

frp already supports SNI-based routing through the vhostHTTPSPort feature. You can configure multiple proxies with different domains, and frps will route traffic based on the SNI field in the TLS Client Hello.

This achieves the same SNI demultiplexing as your Caddy L4 setup.

Note: The proxy type name "https" is somewhat misleading - it performs SNI-based TLS passthrough rather than HTTPS termination. The actual TLS handshake happens at your backend servers. This naming may be refined in future versions to better reflect its behavior.

@fatedier commented on GitHub (Oct 15, 2025): frp already supports SNI-based routing through the vhostHTTPSPort feature. You can configure multiple proxies with different domains, and frps will route traffic based on the SNI field in the TLS Client Hello. This achieves the same SNI demultiplexing as your Caddy L4 setup. Note: The proxy type name "https" is somewhat misleading - it performs SNI-based TLS passthrough rather than HTTPS termination. The actual TLS handshake happens at your backend servers. This naming may be refined in future versions to better reflect its behavior.

gitea-mirror commented

2026-05-05 14:18:59 -06:00

Author

Owner

@gregoiregentil commented on GitHub (Oct 15, 2025):

But this is only for port 443? I want to reroute pop3s (995), imap3s (993) and smtp (465) based on custom domain sent by frpc. Is there another way to do that right now? I have to use haproxy with some specific port for each domain and have frpc to use that specific port.

@gregoiregentil commented on GitHub (Oct 15, 2025): But this is only for port 443? I want to reroute pop3s (995), imap3s (993) and smtp (465) based on custom domain sent by frpc. Is there another way to do that right now? I have to use haproxy with some specific port for each domain and have frpc to use that specific port.

gitea-mirror commented

2026-05-05 14:18:59 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 15, 2025):

Multiple ports are not supported for now; vhostHTTPSPort can only be configured with a single port.

@fatedier commented on GitHub (Oct 15, 2025): Multiple ports are not supported for now; vhostHTTPSPort can only be configured with a single port.

gitea-mirror commented

2026-05-05 14:19:00 -06:00

Author

Owner

@gregoiregentil commented on GitHub (Oct 15, 2025):

I have just tried vhostHTTPSPort on port 995 to transmit POP3s and it seems working with a custom domain setup from frpc! I'm positively surprised that it works because it's not a https transmission though a SSL one.

If it really works for any port on vhostHTTPSPort (which seems to be the case), is there a way to have/patch/get multiples vhostHTTPSPort independently? It would really be extremely beneficial to me because I could get rid of haproxy and to have to put certificates on the server side hosting frps (for haproxy).

As it seems to be working, it's more to tweak/patch the config backend, and have mutliple threads/whatever to handle multiple vhostHTTPSPort. What I'm trying to say is that there is no need to develop a complete new feature...

@gregoiregentil commented on GitHub (Oct 15, 2025): I have just tried vhostHTTPSPort on port 995 to transmit POP3s and it seems working with a custom domain setup from frpc! I'm positively surprised that it works because it's not a https transmission though a SSL one. If it really works for any port on vhostHTTPSPort (which seems to be the case), is there a way to have/patch/get multiples vhostHTTPSPort independently? It would really be extremely beneficial to me because I could get rid of haproxy and to have to put certificates on the server side hosting frps (for haproxy). As it seems to be working, it's more to tweak/patch the config backend, and have mutliple threads/whatever to handle multiple vhostHTTPSPort. What I'm trying to say is that there is no need to develop a complete new feature...

gitea-mirror commented

2026-05-05 14:19:00 -06:00

Author

Owner

@shellus commented on GitHub (Oct 15, 2025):

@gregoiregentil This is not possible at the current stage, but you can use docker to run multiple frps instances

@shellus commented on GitHub (Oct 15, 2025): @gregoiregentil This is not possible at the current stage, but you can use docker to run multiple frps instances

gitea-mirror commented

2026-05-05 14:19:01 -06:00

Author

Owner

@shellus commented on GitHub (Oct 15, 2025):

It's worth mentioning that I have also mapped my local https service in some public frps services, which allows me not to upload my https certificate. This is great.

This indicates that the https in frp configuration is actually sni, which indeed misleads the vast majority of people.

@shellus commented on GitHub (Oct 15, 2025): It's worth mentioning that I have also mapped my local https service in some public frps services, which allows me not to upload my https certificate. This is great. This indicates that the https in frp configuration is actually sni, which indeed misleads the vast majority of people.

gitea-mirror commented

2026-05-05 14:19:01 -06:00

Author

Owner

@fatedier commented on GitHub (Oct 15, 2025):

As it seems to be working, it's more to tweak/patch the config backend, and have mutliple threads/whatever to handle multiple vhostHTTPSPort. What I'm trying to say is that there is no need to develop a complete new feature...

Functionally speaking, yes. However, from the perspective of the current overall architecture design, it is not a feature that can be added easily.
I can only say that it will be supported in the future, but not in the short term.

@fatedier commented on GitHub (Oct 15, 2025): > As it seems to be working, it's more to tweak/patch the config backend, and have mutliple threads/whatever to handle multiple vhostHTTPSPort. What I'm trying to say is that there is no need to develop a complete new feature... Functionally speaking, yes. However, from the perspective of the current overall architecture design, it is not a feature that can be added easily. I can only say that it will be supported in the future, but not in the short term.

gitea-mirror commented

2026-05-05 14:19:02 -06:00

Author

Owner

@gregoiregentil commented on GitHub (Oct 15, 2025):

@shellus I'm not using docker and my experience is that frpc can connect only to one instance of frps at the same time.

@gregoiregentil commented on GitHub (Oct 15, 2025): @shellus I'm not using docker and my experience is that frpc can connect only to one instance of frps at the same time.

gitea-mirror commented

2026-05-05 14:19:02 -06:00

Author

Owner

@gregoiregentil commented on GitHub (Oct 15, 2025):

I completely understand the whole story "not simple, not enough time in the short term". I'm almost willing to patch. Would you share some guidance what would be the very strict minimum (even hard-coding some port numbers) to modify? Or is that too complicated? I'm controlling both ends frps and frpc on my systems.

@gregoiregentil commented on GitHub (Oct 15, 2025): I completely understand the whole story "not simple, not enough time in the short term". I'm almost willing to patch. Would you share some guidance what would be the very strict minimum (even hard-coding some port numbers) to modify? Or is that too complicated? I'm controlling both ends frps and frpc on my systems.

gitea-mirror commented

2026-05-05 14:19:02 -06:00

Author

Owner

@shellus commented on GitHub (Oct 15, 2025):

@shellus I'm not using docker and my experience is that frpc can connect only to one instance of frps at the same time.

I think you've already touched it. Yes, many parts of the system are designed to be unique. As you said, your single frpc can only connect to a single frps, and the same goes for the https port.

So I suggest you, like me, use docker compose to use multiple FRPCS and multiple frps

Trust me, it is very difficult to modify frp itself, but the way to switch and use it is very simple

@shellus commented on GitHub (Oct 15, 2025): > [@shellus](https://github.com/shellus) I'm not using docker and my experience is that frpc can connect only to one instance of frps at the same time. I think you've already touched it. Yes, many parts of the system are designed to be unique. As you said, your single frpc can only connect to a single frps, and the same goes for the https port. So I suggest you, like me, use docker compose to use multiple FRPCS and multiple frps Trust me, it is very difficult to modify frp itself, but the way to switch and use it is very simple

gitea-mirror commented

2026-05-05 14:19:03 -06:00

Author

Owner

@gregoiregentil commented on GitHub (Oct 15, 2025):

Unfortunately, docker is not an option at all (too long to explain why...) If patching isn't possible, I would stay with haproxy. At least, it's on server side only.

@gregoiregentil commented on GitHub (Oct 15, 2025): Unfortunately, docker is not an option at all (too long to explain why...) If patching isn't possible, I would stay with haproxy. At least, it's on server side only.

Rows
Columns

[GH-ISSUE #4558] [Feature Request] add support in frpc for demultiplexing (vhost) multiple HTTPS targets (based on SNI) #3604

Describe the feature request

Describe alternatives you've considered

Affected area