fatedier/frp · error

no route found for source %s

Error message

no route found for source %s

What it means

vnet server-side routing error: serverRouter.findConnBySrc maps source IPs to the client connection that registered them; when a packet's source IP string is not present in srcIPConns, this error is returned. It means the server received tunneled traffic claiming a source address that no frpc connection has registered.

Source

Thrown at pkg/vnet/controller.go:341

// Server router (based solely on source IP routing)
type serverRouter struct {
	srcIPConns map[string]io.Writer // Source IP string to connection mapping
	mu         sync.RWMutex
}

func newServerRouter() *serverRouter {
	return &serverRouter{
		srcIPConns: make(map[string]io.Writer),
	}
}

func (r *serverRouter) findConnBySrc(src net.IP) (io.Writer, error) {
	r.mu.RLock()
	defer r.mu.RUnlock()
	conn, exists := r.srcIPConns[src.String()]
	if !exists {
		return nil, fmt.Errorf("no route found for source %s", src)
	}
	return conn, nil
}

func (r *serverRouter) registerSrcIP(src net.IP, conn io.Writer) {
	key := src.String()

	r.mu.RLock()
	existingConn, ok := r.srcIPConns[key]
	r.mu.RUnlock()

	// If the entry exists and the connection is the same, no need to do anything.
	if ok && existingConn == conn {
		return
	}

	// Acquire write lock to update the map.
	r.mu.Lock()

View on GitHub (pinned to 6c8a8d0a97)

Solutions

1. Ensure frpc's vnet section lists the address ranges it will source traffic from so registration happens at connect
2. Avoid overlapping route/address ranges between multiple vnet clients connecting to the same frps
3. On client restart, give the vnet a moment for re-registration; reconnect the client if errors persist
4. Verify with the source IP in the message which client should own it and add that prefix to its routes

Example fix

# before (frpc has no routes; peer sends from 10.0.0.5)
[vnet]
enabled = true

# after
[vnet]
enabled = true
address = ["10.0.0.1/24"]
routes = ["10.0.0.0/24"]

// ensure the originating side registers its source prefixes
// frpc.toml: vnet.routes must include the ranges traffic will come FROM

When it happens

Trigger: frps vnet router forwarding a packet whose source IP was never registered via route-registration messages; a second frpc overwriting/deregistering routes while traffic is in flight; race at session teardown where routes are removed before queued packets are forwarded; source NAT changing IPs so they no longer equal the registered keys.

Common situations: Routes not configured on frpc so it never registers those source prefixes; multiple clients competing for the same vnet address ranges; stale sessions after a client reconnect — old routes removed, peer still sending from those IPs.

Related errors

• no route found for destination %s
• parse route %s error: %v
• subdomain is not supported because this feature is not enabl
• '.' and '*' are not supported in subdomain
• create encryption stream error: %v

AI-assisted analysis of fatedier/frp@6c8a8d0a97 (2026-08-15). Data as JSON: /api/errors/fd217fd549351857. Report an issue: GitHub.