github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00

[GH-ISSUE #4937] [Feature Request] Enhanced Interface Binding Support #3894

New issue

Closed

opened 2026-05-05 14:29:05 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 14:29:05 -06:00

Owner

Originally created by @jeet0733 on GitHub (Aug 15, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4937

Describe the feature request

Description

Add support for network interface binding in FRP client connections, allowing users to specify which network interface to use when connecting to the FRP server through interface names or auto-detection, in addition to the existing IP address binding. I have developed it, kindly approve this feature and I will submit the PR.

Currently, frp supports:

✅ IP address binding via connectServerLocalIP
✅ TCP, HTTP, HTTPS, WebSocket, UDP, STCP, QUIC protocols
❌ Interface name binding (missing)
❌ Command line interface binding options (missing)

This feature request adds the missing interface binding capabilities.

Implementation Approach

New network interface utilities for cross-platform interface resolution
Enhanced client configuration with connectServerInterface field
Interface name to IP address resolution with validation
Auto-detection for first available non-loopback interface
Command line flags (--bind-interface, --bind-ip) for runtime configuration
Priority system: CLI flags > config interface > config IP > system default
Integration with existing connection establishment logic
Validation and error handling

Use Cases

Multi-homed systems with multiple network interfaces (management, data, backup networks)
Containerized environments with dynamic networking (Docker, Kubernetes)
Load balancing scenarios requiring specific network paths
Network segmentation for security and traffic isolation
Mobile/edge devices with changing network interfaces (WiFi, cellular, ethernet)
Cloud environments with complex network topologies

Configuration Example

# Enhanced Interface Binding
[transport]
# Option 1: Interface name binding
connectServerInterface = "eth0"

# Option 2: Auto-detection
# connectServerInterface = "auto"

# Option 3: IP address binding (backward compatible)
# connectServerLocalIP = "192.168.1.100"

Command Line Interface

# Interface name binding
./frpc --bind-interface eth0 -c frpc.toml

# Auto-detection
./frpc --bind-interface auto -c frpc.toml

# IP address binding (existing functionality)
./frpc --bind-ip 192.168.1.100 -c frpc.toml

# Protocol-specific commands
./frpc tcp --bind-interface eth0 --local-ip 127.0.0.1 --local-port 22 --remote-port 6000
./frpc http --bind-interface eth0 --custom-domain example.com --local-port 80
./frpc https --bind-interface eth0 --custom-domain secure.example.com --local-port 443

Benefits

Simplifies network configuration by using interface names instead of IP addresses
Enables automatic interface detection for dynamic network environments
Maintains full backward compatibility with existing connectServerLocalIP configurations
Provides flexible binding options through both configuration files and command line
Supports all major protocols (TCP, HTTP, HTTPS, UDP, STCP, QUIC)
Cross-platform compatibility across Linux, macOS, and Windows
Reduces manual network configuration in containerized and cloud environments

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 @jeet0733 on GitHub (Aug 15, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4937 ### Describe the feature request ### Description Add support for network interface binding in FRP client connections, allowing users to specify which network interface to use when connecting to the FRP server through interface names or auto-detection, in addition to the existing IP address binding. **I have developed it, kindly approve this feature and I will submit the PR.** Currently, frp supports: - ✅ IP address binding via `connectServerLocalIP` - ✅ TCP, HTTP, HTTPS, WebSocket, UDP, STCP, QUIC protocols - ❌ Interface name binding (missing) - ❌ Command line interface binding options (missing) This feature request adds the missing interface binding capabilities. ### Implementation Approach - New network interface utilities for cross-platform interface resolution - Enhanced client configuration with `connectServerInterface` field - Interface name to IP address resolution with validation - Auto-detection for first available non-loopback interface - Command line flags (`--bind-interface`, `--bind-ip`) for runtime configuration - Priority system: CLI flags > config interface > config IP > system default - Integration with existing connection establishment logic - Validation and error handling ### Use Cases - Multi-homed systems with multiple network interfaces (management, data, backup networks) - Containerized environments with dynamic networking (Docker, Kubernetes) - Load balancing scenarios requiring specific network paths - Network segmentation for security and traffic isolation - Mobile/edge devices with changing network interfaces (WiFi, cellular, ethernet) - Cloud environments with complex network topologies ### Configuration Example ```toml # Enhanced Interface Binding [transport] # Option 1: Interface name binding connectServerInterface = "eth0" # Option 2: Auto-detection # connectServerInterface = "auto" # Option 3: IP address binding (backward compatible) # connectServerLocalIP = "192.168.1.100" ``` ### Command Line Interface ```bash # Interface name binding ./frpc --bind-interface eth0 -c frpc.toml # Auto-detection ./frpc --bind-interface auto -c frpc.toml # IP address binding (existing functionality) ./frpc --bind-ip 192.168.1.100 -c frpc.toml # Protocol-specific commands ./frpc tcp --bind-interface eth0 --local-ip 127.0.0.1 --local-port 22 --remote-port 6000 ./frpc http --bind-interface eth0 --custom-domain example.com --local-port 80 ./frpc https --bind-interface eth0 --custom-domain secure.example.com --local-port 443 ``` ### Benefits - Simplifies network configuration by using interface names instead of IP addresses - Enables automatic interface detection for dynamic network environments - Maintains full backward compatibility with existing `connectServerLocalIP` configurations - Provides flexible binding options through both configuration files and command line - Supports all major protocols (TCP, HTTP, HTTPS, UDP, STCP, QUIC) - Cross-platform compatibility across Linux, macOS, and Windows - Reduces manual network configuration in containerized and cloud environments ### Describe alternatives you've considered _No response_ ### Affected area - [x] 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:29:05 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:29:09 -06:00

Author

Owner

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

Thanks for the suggestion, but we don’t have plans to add this feature for now.

@fatedier commented on GitHub (Aug 15, 2025): Thanks for the suggestion, but we don’t have plans to add this feature for now.

gitea-mirror commented

2026-05-05 14:29:10 -06:00

Author

Owner

@jeet0733 commented on GitHub (Aug 18, 2025):

Hi fatedier, supporting the interface binding can really help where the IP of interface is not known in advance such as vpn interfaces. Another similar request was open at 3376 but was addressed with IP allocation workaround.

Since it requires minimal code changes, I would request you to review it once at 4943

@jeet0733 commented on GitHub (Aug 18, 2025): Hi fatedier, supporting the interface binding can really help where the IP of interface is not known in advance such as vpn interfaces. Another similar request was open at [3376](https://github.com/fatedier/frp/issues/3376) but was addressed with IP allocation workaround. Since it requires minimal code changes, I would request you to review it once at [4943](https://github.com/fatedier/frp/pull/4943)

gitea-mirror commented

2026-05-05 14:29:10 -06:00

Author

Owner

@fatedier commented on GitHub (Aug 18, 2025):

Thank you for your submission. We do not intend to support this feature.

@fatedier commented on GitHub (Aug 18, 2025): Thank you for your submission. We do not intend to support this feature.

gitea-mirror commented

2026-05-05 14:29:11 -06:00

Author

Owner

@f0re1gnKey commented on GitHub (Aug 20, 2025):

Hi fatedier, supporting the interface binding can really help where the IP of interface is not known in advance such as vpn interfaces. Another similar request was open at 3376 but was addressed with IP allocation workaround.

Since it requires minimal code changes, I would request you to review it once at 4943

This developer is quite stubborn and sticks to what he calls his own principles.

Therefore, if you have new requirements, I recommend forking and modifying it yourself.

The developers said that you shouldn't add too much irrelevant content to frp, but in my opinion, all the http and ui related content is redundant, they can't be better than nginx/apache.

@f0re1gnKey commented on GitHub (Aug 20, 2025): > Hi fatedier, supporting the interface binding can really help where the IP of interface is not known in advance such as vpn interfaces. Another similar request was open at [3376](https://github.com/fatedier/frp/issues/3376) but was addressed with IP allocation workaround. > > Since it requires minimal code changes, I would request you to review it once at [4943](https://github.com/fatedier/frp/pull/4943) This developer is quite stubborn and sticks to what he calls his own principles. Therefore, if you have new requirements, I recommend forking and modifying it yourself. The developers said that you shouldn't add too much irrelevant content to frp, but in my opinion, all the http and ui related content is redundant, they can't be better than nginx/apache.

gitea-mirror commented

2026-05-05 14:29:11 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 4, 2025):

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 (Sep 4, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.