[GH-ISSUE #518] Run server with bind_port = 443 and also handle HTTPS connections like ngrok does. #399

New issue

Closed

opened 2026-05-05 12:12:47 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 12:12:47 -06:00

Owner

Originally created by @keyoti on GitHub (Nov 10, 2017).
Original GitHub issue: https://github.com/fatedier/frp/issues/518

I apologise if I am wrong in any of my understanding below.

Some firewalls/proxy setups restrict outgoing connections to limited ports (eg 80 and 443).

FRP seems to use bind_port = 7000 for handling control connections coming in from the client.

ngrok seems to be able to handle client control connections on port 443 and also HTTPS connections from browsers. It does this with

// Listen for incoming control and proxy connections
// We listen for incoming control and proxy connections on the same port
// for ease of deployment. The hope is that by running on port 443, using
// TLS and running all connections over the same port, we can bust through
// restrictive firewalls.

func tunnelListener(addr string, tlsConfig *tls.Config) {
	// listen for incoming connections
	listener, err := conn.Listen(addr, "tun", tlsConfig)
	if err != nil {
		panic(err)
	}

	log.Info("Listening for control and proxy connections on %s", listener.Addr.String())
	for c := range listener.Conns {
		go func(tunnelConn conn.Conn) {
			// don't crash on panics
			defer func() {
				if r := recover(); r != nil {
					tunnelConn.Info("tunnelListener failed with error %v: %s", r, debug.Stack())
				}
			}()

			tunnelConn.SetReadDeadline(time.Now().Add(connReadTimeout))
			var rawMsg msg.Message
			if rawMsg, err = msg.ReadMsg(tunnelConn); err != nil {
				tunnelConn.Warn("Failed to read message: %v", err)
				tunnelConn.Close()
				return
			}

			// don't timeout after the initial read, tunnel heartbeating will kill
			// dead connections
			tunnelConn.SetReadDeadline(time.Time{})

			switch m := rawMsg.(type) {
			case *msg.Auth:
				NewControl(tunnelConn, m)

			case *msg.RegProxy:
				NewProxy(tunnelConn, m)

			default:
				tunnelConn.Close()
			}
		}(c)
	}
}

It differentiates between control connections and proxy connections in the switch.

Do you believe it would be possible to do the same in FRP? I'm willing to try to do it, but it'd be great to get some insight on the feasibility and also where to start.

Originally created by @keyoti on GitHub (Nov 10, 2017). Original GitHub issue: https://github.com/fatedier/frp/issues/518 I apologise if I am wrong in any of my understanding below. Some firewalls/proxy setups restrict outgoing connections to limited ports (eg 80 and 443). FRP seems to use bind_port = 7000 for handling control connections coming in from the client. ngrok seems to be able to handle client control connections on port 443 and also HTTPS connections from browsers. It does this with ``` // Listen for incoming control and proxy connections // We listen for incoming control and proxy connections on the same port // for ease of deployment. The hope is that by running on port 443, using // TLS and running all connections over the same port, we can bust through // restrictive firewalls. func tunnelListener(addr string, tlsConfig *tls.Config) { // listen for incoming connections listener, err := conn.Listen(addr, "tun", tlsConfig) if err != nil { panic(err) } log.Info("Listening for control and proxy connections on %s", listener.Addr.String()) for c := range listener.Conns { go func(tunnelConn conn.Conn) { // don't crash on panics defer func() { if r := recover(); r != nil { tunnelConn.Info("tunnelListener failed with error %v: %s", r, debug.Stack()) } }() tunnelConn.SetReadDeadline(time.Now().Add(connReadTimeout)) var rawMsg msg.Message if rawMsg, err = msg.ReadMsg(tunnelConn); err != nil { tunnelConn.Warn("Failed to read message: %v", err) tunnelConn.Close() return } // don't timeout after the initial read, tunnel heartbeating will kill // dead connections tunnelConn.SetReadDeadline(time.Time{}) switch m := rawMsg.(type) { case *msg.Auth: NewControl(tunnelConn, m) case *msg.RegProxy: NewProxy(tunnelConn, m) default: tunnelConn.Close() } }(c) } } ``` It differentiates between control connections and proxy connections in the switch. Do you believe it would be possible to do the same in FRP? I'm willing to try to do it, but it'd be great to get some insight on the feasibility and also where to start.

gitea-mirror

2026-05-05 12:12:47 -06:00

closed this issue
added the
todo
label

gitea-mirror commented

2026-05-05 12:12:52 -06:00

Author

Owner

@fatedier commented on GitHub (Nov 12, 2017):

I'm not sure if the code you paste from ngrok shows that it can handle client control connections and HTTPS connections from browsers in the same port? msg.Auth and msg.RegProxy are messages got from ngrok client, there is no case for https connections.

But i think it's really a good idea for some special users. It's welcome for you to contribute code for this feature.

I have some ideas:

We should be able to distinguish the connection types (frp internal protocol or http or https connection?) from some bytes in the beginning of the connection.
Construct a special listener to handle all connections and detect it's connection type, then forward it to other listeners.

@fatedier commented on GitHub (Nov 12, 2017): I'm not sure if the code you paste from ngrok shows that it can handle client control connections and HTTPS connections from browsers in the same port? **msg.Auth** and **msg.RegProxy** are messages got from ngrok client, there is no case for https connections. But i think it's really a good idea for some special users. It's welcome for you to contribute code for this feature. I have some ideas: 1. We should be able to distinguish the connection types (frp internal protocol or http or https connection?) from some bytes in the beginning of the connection. 2. Construct a special listener to handle all connections and detect it's connection type, then forward it to other listeners.

gitea-mirror commented

2026-05-05 12:12:54 -06:00

Author

Owner

@fatedier commented on GitHub (May 6, 2018):

It will be supported in next version v0.19.0.

@fatedier commented on GitHub (May 6, 2018): It will be supported in next version v0.19.0.

gitea-mirror commented

2026-05-05 12:12:55 -06:00

Author

Owner

@fatedier commented on GitHub (May 14, 2018):