github-starred/frp

Fork 0

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

[GH-ISSUE #2696] "start error: port unavailable" when "bind_addr" was set to :: #2149

New issue

Closed

opened 2026-05-05 13:22:56 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 13:22:56 -06:00

Owner

Originally created by @eat-swap on GitHub (Dec 9, 2021).
Original GitHub issue: https://github.com/fatedier/frp/issues/2696

Bug Description

To whom it may concerned,

When I was trying to run the program after setting up the configuration, a weird phenomenon was observed. Both frpc and frps complain that "start error: port unavailable" even in such conditions:

Both frpc and frps was ran using the root user.
Any port specified in frpc configuration file was NOT listened or occupied.

No working solution was found when searching across the web. However, the problem could be resolved simply by commenting out the bind_addr entry in frps configuration file. Like this:

# bind_addr = ::

When trying to uncomment it, the problem could be reproduced. That's weird because it is not expected to break the program when doing this.

frpc Version

0.38.0

frps Version

0.38.0

System Architecture

linux/amd64

Configurations

For your reference,

frpc.ini

[common]

server_addr = 127.0.0.1
server_port = 60007

log_file = console
log_level = info

login_fail_exit = false
protocol = tcp

token = [REDACTED]

admin_addr = 127.255.254.2
admin_port = 60057

[rdpTcp]
type = tcp
local_ip = [REDACTED]
local_port = 3389
remote_port = 3389

[rdpUdp]
type = udp
local_ip = [REDACTED]
local_port = 3389
remote_port = 3389

[vncTcp]
type = tcp
local_ip = [REDACTED]
local_port = 5900
remote_port = 5900

[vncUdp]
type = udp
local_ip = [REDACTED]
local_port = 5900
remote_port = 5900

[hostSsh]
type = tcp
local_ip = [REDACTED]
local_port = 22
remote_port = 62002

frps.ini

[common]

bind_addr = ::
bind_port = 60007
bind_udp_port = 60007
kcp_bind_port = 60008

log_file = console
log_level = debug

detailed_errors_to_client = true

token = [REDACTED]

dashboard_addr = 127.255.254.1
dashboard_port = 60057
dashboard_user = [REDACTED]
dashboard_pwd = [REDACTED]

Logs

Output of frps:

2021/12/09 17:30:29 [I] [service.go:447] [7681052d26b109ee] client login info: ip [[some:ipv6:addr:ess]:34698] version [0.38.0] hostname [] os [linux] arch [amd64]
2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [hostSsh] error: port unavailable
2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [rdpUdp] error: acquire port 3389 error: port unavailable
2021/12/09 17:30:29 [D] [control.go:219] [7681052d26b109ee] new work connection registered
2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [rdpTcp] error: port unavailable
2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [vncTcp] error: port unavailable
2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [vncUdp] error: acquire port 5900 error: port unavailable

And the same of frpc:

2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [hostSsh] start error: port unavailable
2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [rdpUdp] start error: acquire port 3389 error: port unavailable
2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [rdpTcp] start error: port unavailable
2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [vncTcp] start error: port unavailable
2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [vncUdp] start error: acquire port 5900 error: port unavailable

Steps to reproduce

Follow the steps below:

Place frpc and frps on the same machine.
Edit configuration file, as mentioned above.
Start frps.
Start frpc after frps starts.
Reproduced.

For your reference, the operating systems tested were Arch Linux and OpenWrt, kernel Linux 5.15.7-zen1-1-zen x86_64.

Affected area

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

Originally created by @eat-swap on GitHub (Dec 9, 2021). Original GitHub issue: https://github.com/fatedier/frp/issues/2696 ### Bug Description To whom it may concerned, When I was trying to run the program after setting up the configuration, a weird phenomenon was observed. Both frpc and frps complain that "start error: port unavailable" even in such conditions: - Both frpc and frps was ran using the `root` user. - Any port specified in frpc configuration file was NOT listened or occupied. No working solution was found when searching across the web. However, the problem could be resolved simply by commenting out the `bind_addr` entry in frps configuration file. Like this: ``` # bind_addr = :: ``` When trying to uncomment it, the problem could be reproduced. That's weird because it is not expected to break the program when doing this. ### frpc Version 0.38.0 ### frps Version 0.38.0 ### System Architecture linux/amd64 ### Configurations For your reference, - frpc.ini ``` [common] server_addr = 127.0.0.1 server_port = 60007 log_file = console log_level = info login_fail_exit = false protocol = tcp token = [REDACTED] admin_addr = 127.255.254.2 admin_port = 60057 [rdpTcp] type = tcp local_ip = [REDACTED] local_port = 3389 remote_port = 3389 [rdpUdp] type = udp local_ip = [REDACTED] local_port = 3389 remote_port = 3389 [vncTcp] type = tcp local_ip = [REDACTED] local_port = 5900 remote_port = 5900 [vncUdp] type = udp local_ip = [REDACTED] local_port = 5900 remote_port = 5900 [hostSsh] type = tcp local_ip = [REDACTED] local_port = 22 remote_port = 62002 ``` - frps.ini ``` [common] bind_addr = :: bind_port = 60007 bind_udp_port = 60007 kcp_bind_port = 60008 log_file = console log_level = debug detailed_errors_to_client = true token = [REDACTED] dashboard_addr = 127.255.254.1 dashboard_port = 60057 dashboard_user = [REDACTED] dashboard_pwd = [REDACTED] ``` ### Logs Output of frps: ``` 2021/12/09 17:30:29 [I] [service.go:447] [7681052d26b109ee] client login info: ip [[some:ipv6:addr:ess]:34698] version [0.38.0] hostname [] os [linux] arch [amd64] 2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [hostSsh] error: port unavailable 2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [rdpUdp] error: acquire port 3389 error: port unavailable 2021/12/09 17:30:29 [D] [control.go:219] [7681052d26b109ee] new work connection registered 2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [rdpTcp] error: port unavailable 2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [vncTcp] error: port unavailable 2021/12/09 17:30:29 [W] [control.go:440] [7681052d26b109ee] new proxy [vncUdp] error: acquire port 5900 error: port unavailable ``` And the same of frpc: ``` 2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [hostSsh] start error: port unavailable 2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [rdpUdp] start error: acquire port 3389 error: port unavailable 2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [rdpTcp] start error: port unavailable 2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [vncTcp] start error: port unavailable 2021/12/09 17:30:29 [W] [control.go:178] [7681052d26b109ee] [vncUdp] start error: acquire port 5900 error: port unavailable ``` ### Steps to reproduce Follow the steps below: - Place frpc and frps on the same machine. - Edit configuration file, as mentioned above. - Start frps. - Start frpc after frps starts. - Reproduced. For your reference, the operating systems tested were Arch Linux and OpenWrt, kernel `Linux 5.15.7-zen1-1-zen x86_64`. ### Affected area - [ ] Docs - [x] Installation - [ ] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 13:22:56 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 13:23:00 -06:00

Author

Owner

@raisin8010 commented on GitHub (Dec 11, 2021):

see #2346

@raisin8010 commented on GitHub (Dec 11, 2021): see #2346

gitea-mirror commented

2026-05-05 13:23:01 -06:00

Author

Owner

@eat-swap commented on GitHub (Dec 11, 2021):

see #2346

Thanks for pointing out that. However this should be considered as a bug since this weird bug is bothering users including you and me. #2346 does not include any type of solution. Leaving the bug unresolved may cause the same issue opened again and again (like this one).

@eat-swap commented on GitHub (Dec 11, 2021): > see #2346 Thanks for pointing out that. However this should be considered as a bug since this weird bug is bothering users including you and me. #2346 does not include any type of solution. Leaving the bug unresolved may cause the same issue opened again and again (like this one).

gitea-mirror commented

2026-05-05 13:23:02 -06:00

Author

Owner

@showgood163 commented on GitHub (Jan 1, 2022):

I can reproduce this problem w/ frpc & frps 0.38.0.

Downgrade frps to 0.36.1 fixes the problem

@showgood163 commented on GitHub (Jan 1, 2022): I can reproduce this problem w/ frpc & frps 0.38.0. Downgrade frps to 0.36.1 fixes the problem

gitea-mirror commented

2026-05-05 13:23:02 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Feb 1, 2022):

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

gitea-mirror commented

2026-05-05 13:23:02 -06:00

Author

Owner

@raisin8010 commented on GitHub (Feb 1, 2022):

Please take a look at this issue. @fatedier

@raisin8010 commented on GitHub (Feb 1, 2022): Please take a look at this issue. @fatedier

gitea-mirror commented

2026-05-05 13:23:03 -06:00

Author

Owner

@fatedier commented on GitHub (Feb 9, 2022):