[GH-ISSUE #4806] No effect on remote port number in ssh command

gitea-mirror commented

2026-05-05 14:25:45 -06:00

Owner

Copy link

Originally created by @itsKV on GitHub (May 21, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4806

Bug Description

If I use following command to forward local service to server, port gets forwarded successfully.

ssh -R :9999:127.0.0.1:80 sub.domain.tld -p 220 http -n "test-http" --sd test1 -t 12345

But the remote port mentioned here 9999 seems just a placeholder as vhostHTTPPort is coded in frps's config file itself and server serves the local hosted site on that vhostHTTPPort port only and not on 9999. Further, any number can be used at this place and server still accepts the ssh command and starts serving on port vhostHTTPPort .

Is this correct behavior of the frps or there should be error output to ssh client if this number differs from vhostHTTPPort port ?

frpc Version

windows 11 native ssh

frps Version

0.62.1

System Architecture

linux/arm64

Configurations

bindAddr = "0.0.0.0"
bindPort = 1234
kcpBindPort = 1234

webServer.addr = "127.0.0.1"
webServer.port = 7500
webServer.user = "adm"
webServer.password = "adm"

vhostHTTPPort = 8880

auth.method = "token"
auth.token = "12345"

subDomainHost = "sub.domain.tld"

allowPorts = [ { start = 10000, end = 50000 } ]

sshTunnelGateway.bindPort = 220

Logs

No response

Steps to reproduce

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 @itsKV on GitHub (May 21, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4806 ### Bug Description If I use following command to forward local service to server, port gets forwarded successfully. `ssh -R :9999:127.0.0.1:80 sub.domain.tld -p 220 http -n "test-http" --sd test1 -t 12345` But the remote port mentioned here 9999 seems just a placeholder as vhostHTTPPort is coded in frps's config file itself and server serves the local hosted site on that vhostHTTPPort port only and not on 9999. Further, any number can be used at this place and server still accepts the ssh command and starts serving on port vhostHTTPPort . Is this correct behavior of the frps or there should be error output to ssh client if this number differs from vhostHTTPPort port ? ### frpc Version windows 11 native ssh ### frps Version 0.62.1 ### System Architecture linux/arm64 ### Configurations bindAddr = "0.0.0.0" bindPort = 1234 kcpBindPort = 1234 webServer.addr = "127.0.0.1" webServer.port = 7500 webServer.user = "adm" webServer.password = "adm" vhostHTTPPort = 8880 auth.method = "token" auth.token = "12345" subDomainHost = "sub.domain.tld" allowPorts = [ { start = 10000, end = 50000 } ] sshTunnelGateway.bindPort = 220 ### Logs _No response_ ### Steps to reproduce _No response_ ### Affected area - [ ] Docs - [ ] Installation - [x] Performance and Scalability - [ ] Security - [x] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror

2026-05-05 14:25:45 -06:00

closed this issue
added the
lifecycle/stale
label

gitea-mirror commented

2026-05-05 14:25:47 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (May 22, 2025):

Hi @itsKV,

The behavior you're observing is generally expected within frp's design for handling HTTP/HTTPS virtual hosts (vhosts). Here's a breakdown:

vhostHTTPPort for HTTP Proxies: When vhostHTTPPort is set in frps.toml (e.g., to 8880), frps is designed to route all HTTP requests for proxies that use subdomains (like your --sd test1) or custom domains through this single port. It then uses the HTTP Host header to direct traffic to the correct backend. This allows multiple web services to share a common entry port.

The SSH command itself is valid for tunnel creation. frps then applies its own routing rules for the proxy type. It doesn't currently treat this difference as an error because it prioritizes the vhost mechanism for these proxy types.

In summary:

For your setup, accessing the service via http://test1.sub.domain.tld:8880 is the correct and intended way.
The port 9999 in the ssh -R command is effectively ignored for determining the public listening port for this specific HTTP vhost proxy.

Hope this explanation helps!

@fatedier commented on GitHub (May 22, 2025): Hi @itsKV, The behavior you're observing is generally expected within frp's design for handling HTTP/HTTPS virtual hosts (vhosts). Here's a breakdown: vhostHTTPPort for HTTP Proxies: When vhostHTTPPort is set in frps.toml (e.g., to 8880), frps is designed to route all HTTP requests for proxies that use subdomains (like your --sd test1) or custom domains through this single port. It then uses the HTTP Host header to direct traffic to the correct backend. This allows multiple web services to share a common entry port. The SSH command itself is valid for tunnel creation. frps then applies its own routing rules for the proxy type. It doesn't currently treat this difference as an error because it prioritizes the vhost mechanism for these proxy types. In summary: For your setup, accessing the service via http://test1.sub.domain.tld:8880 is the correct and intended way. The port 9999 in the ssh -R command is effectively ignored for determining the public listening port for this specific HTTP vhost proxy. Hope this explanation helps!

gitea-mirror commented

2026-05-05 14:25:48 -06:00

Author

Owner

Copy link

@itsKV commented on GitHub (May 22, 2025):

That's clear.

Omitting port number from the command, ssh itself throws the error as the remote port is required for -R switch to work.
frps will however work only with the port configured at vhostHTTPPort

We can issue the error (from server side) at the commands output itself terminating the session immediately if port number differs from vhostHTTPPort config. frps's ssh-tcp mode currently issues such error if user inputs out of the limit port than mentioned in allowPorts config.

@itsKV commented on GitHub (May 22, 2025): That's clear. - Omitting port number from the command, ssh itself throws the error as the remote port is required for -R switch to work. - frps will however work only with the port configured at `vhostHTTPPort` We can issue the error (from server side) at the commands output itself terminating the session immediately if port number differs from `vhostHTTPPort` config. frps's ssh-tcp mode currently issues such error if user inputs out of the limit port than mentioned in `allowPorts` config.

gitea-mirror commented

2026-05-05 14:25:49 -06:00

Author

Owner

Copy link

@github-actions[bot] commented on GitHub (Jun 6, 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 (Jun 6, 2025): Issues go stale after 14d of inactivity. Stale issues rot after an additional 3d of inactivity and eventually close.

No Branch/Tag specified