What causes "new proxy configurer error" in fatedier/frp?

If maintaining a fork, ensure every entry in supportTypes has a corresponding entry in v1's proxy configurer registry.

new proxy configurer error

Error message

new proxy configurer error

What it means

Emitted when v1.NewProxyConfigurerByType returns nil for the requested proxy type. Because the type string was already validated against the supported list (tcp/http/https/tcpmux/stcp) immediately before, every accepted value has a registered configurer; this branch is defensive dead code guarding against the supported-types list and the registry drifting apart.

Source

Thrown at pkg/ssh/server.go:280

	cmd := &cobra.Command{
		Use:   "ssh v0@{address} [command]",
		Short: "ssh v0@{address} [command]",
		Run:   func(*cobra.Command, []string) {},
	}
	cmd.SetGlobalNormalizationFunc(config.WordSepNormalizeFunc)

	args := strings.Split(extraPayload, " ")
	if len(args) < 1 {
		return nil, nil, helpMessage, fmt.Errorf("invalid extra payload")
	}
	proxyType := strings.TrimSpace(args[0])
	supportTypes := []string{"tcp", "http", "https", "tcpmux", "stcp"}
	if !slices.Contains(supportTypes, proxyType) {
		return nil, nil, helpMessage, fmt.Errorf("invalid proxy type: %s, support types: %v", proxyType, supportTypes)
	}
	pc := v1.NewProxyConfigurerByType(v1.ProxyType(proxyType))
	if pc == nil {
		return nil, nil, helpMessage, fmt.Errorf("new proxy configurer error")
	}
	config.RegisterProxyFlags(cmd, pc, config.WithSSHMode())

	clientCfg := v1.ClientCommonConfig{}
	config.RegisterClientCommonConfigFlags(cmd, &clientCfg, config.WithSSHMode())

	cmd.InitDefaultHelpCmd()
	if err := cmd.ParseFlags(args); err != nil {
		if errors.Is(err, flag.ErrHelp) {
			helpMessage = cmd.UsageString()
		}
		return nil, nil, helpMessage, err
	}
	// if name is not set, generate a random one
	if pc.GetBaseConfig().Name == "" {
		id, err := util.RandIDWithLen(8)
		if err != nil {
			return nil, nil, helpMessage, fmt.Errorf("generate random id error: %v", err)

View on GitHub (pinned to 6c8a8d0a97)

Solutions

If maintaining a fork, ensure every entry in supportTypes has a corresponding entry in v1's proxy configurer registry.
In upstream builds, treat this as an internal invariant failure — report the frps/client version pair in a bug report.

Defensive patterns

Strategy: validation

Prevention

Upstream builds cannot hit this — no runtime defense needed.
Fork maintainers: keep the supportTypes slice in sync with v1's proxy configurer registry (add a unit test asserting NewProxyConfigurerByType != nil for every entry).

When it happens

Trigger: Only reachable if the supportTypes slice and NewProxyConfigurerByType's registry become inconsistent (e.g. a fork adds a type to supportTypes without registering a configurer, or a new core proxy type is added without updating the SSH allowlist).

Common situations: Custom frp forks or downstream patches; effectively never in upstream releases.

Related errors

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