[GH-ISSUE #3430] [Feature Request] Support for remote_unix_path

gitea-mirror commented

2026-05-05 13:46:13 -06:00

Owner

Originally created by @pierre-pretorius on GitHub (Apr 29, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3430

Describe the feature request

Below is a very simple example that is already possible:

# frpc.ini
[web]
type = tcp
local_port = 80
remote_port = 6000

It would be very useful if you can create a remote unix socket instead of a remote listening port:

# frpc.ini
[web]
type = tcp
local_port = 80
remote_unix_path = /var/run/web_6000.sock

Why? If the server is exposing these ports through something like nginx or a custom application, then it can connect via unix socket instead of TCP socket to scale to more clients. Currently if there are many clients, it will cause many listening connections and sockets:

cat /proc/net/sockstat
  sockets: used 11522
  TCP: inuse 615 orphan 23 tw 1017 alloc 11015 mem 806
  UDP: inuse 8 mem 5
  UDPLITE: inuse 0
  RAW: inuse 0
  FRAG: inuse 0 memory 0

netstat -tulpn | grep LISTEN | wc -l
  6777

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 @pierre-pretorius on GitHub (Apr 29, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3430 ### Describe the feature request Below is a very simple example that is already possible: ``` # frpc.ini [web] type = tcp local_port = 80 remote_port = 6000 ``` It would be very useful if you can create a remote unix socket instead of a remote listening port: ``` # frpc.ini [web] type = tcp local_port = 80 remote_unix_path = /var/run/web_6000.sock ``` Why? If the server is exposing these ports through something like nginx or a custom application, then it can connect via unix socket instead of TCP socket to scale to more clients. Currently if there are many clients, it will cause many listening connections and sockets: ``` cat /proc/net/sockstat sockets: used 11522 TCP: inuse 615 orphan 23 tw 1017 alloc 11015 mem 806 UDP: inuse 8 mem 5 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0 netstat -tulpn | grep LISTEN | wc -l 6777 ``` ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [X] Performance and Scalability - [ ] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:46:13 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 13:46:16 -06:00

Author

Owner

@fatedier commented on GitHub (May 4, 2023):

I am somewhat concerned about the potential security risks. Because UDS is often used in various Linux tools, there may be a risk of hijacking.

In the scenario of intranet penetration, such optimization can be almost negligible.

Currently if there are many clients, it will cause many listening connections and sockets:

This should not be a big problem. For the HTTP protocol, there is no need to do mapping through ports, only through vhost_http_port to reuse the port. With proper configuration, Linux can handle a very high number of concurrent requests.

@fatedier commented on GitHub (May 4, 2023): I am somewhat concerned about the potential security risks. Because UDS is often used in various Linux tools, there may be a risk of hijacking. In the scenario of intranet penetration, such optimization can be almost negligible. > Currently if there are many clients, it will cause many listening connections and sockets: This should not be a big problem. For the HTTP protocol, there is no need to do mapping through ports, only through `vhost_http_port` to reuse the port. With proper configuration, Linux can handle a very high number of concurrent requests.

gitea-mirror commented

2026-05-05 13:46:18 -06:00

Author

Owner

@pierre-pretorius commented on GitHub (Jun 22, 2023):

Similar to the allow_ports setting, there could be a allow_unix_path where you could limit usage to be within a certain directory such as /var/run/some_app/.

I understand if this request is too specific to our usecase. We can consider forking the project if we run into problems with the existing TCP approach in the future. I note what you say about the vhost_http_port, we will re-evaluate this option. I believe in the past there was an issue with using websockets through it.

@pierre-pretorius commented on GitHub (Jun 22, 2023): Similar to the `allow_ports` setting, there could be a `allow_unix_path` where you could limit usage to be within a certain directory such as `/var/run/some_app/`. I understand if this request is too specific to our usecase. We can consider forking the project if we run into problems with the existing TCP approach in the future. I note what you say about the `vhost_http_port`, we will re-evaluate this option. I believe in the past there was an issue with using websockets through it.

gitea-mirror commented

2026-05-05 13:46:18 -06:00

Author

Owner

@fatedier commented on GitHub (Jun 25, 2023):

Similar to the allow_ports setting, there could be a allow_unix_path where you could limit usage to be within a certain directory such as /var/run/some_app/

If this requirement is commonly present, then we can consider it.

I understand if this request is too specific to our usecase. We can consider forking the project if we run into problems with the existing TCP approach in the future. I note what you say about the vhost_http_port, we will re-evaluate this option. I believe in the past there was an issue with using websockets through it.

I tend to prefer solving the problems encountered in the current situation first, and only consider other solutions when it is truly impossible to solve them. You can provide more information about the problem and if possible, try to reproduce it locally. This will help me identify the root cause of the issue.

@fatedier commented on GitHub (Jun 25, 2023): > Similar to the allow_ports setting, there could be a allow_unix_path where you could limit usage to be within a certain directory such as /var/run/some_app/ If this requirement is commonly present, then we can consider it. > I understand if this request is too specific to our usecase. We can consider forking the project if we run into problems with the existing TCP approach in the future. I note what you say about the vhost_http_port, we will re-evaluate this option. I believe in the past there was an issue with using websockets through it. I tend to prefer solving the problems encountered in the current situation first, and only consider other solutions when it is truly impossible to solve them. You can provide more information about the problem and if possible, try to reproduce it locally. This will help me identify the root cause of the issue.

gitea-mirror commented

2026-05-05 13:46:18 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 12, 2023):

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 (Oct 12, 2023): Issues go stale after 30d of inactivity. Stale issues rot after an additional 7d of inactivity and eventually close.