fatedier/frp · error

local_port and remote_port is necessary

Error message

local_port and remote_port is necessary

What it means

Defensive check after range expansion: the local port list must contain at least one entry. In practice it is nearly unreachable — util.ParseRangeNumbers returns an error for empty or non-numeric strings before this point, and the empty-string case is already rejected by the earlier 'local_port or remote_port is empty' check. It guards against future parser changes that could yield zero ports from a non-empty input.

Source

Thrown at pkg/config/legacy/client.go:312

		return fmt.Errorf("local_port or remote_port is empty")
	}

	localPorts, err := util.ParseRangeNumbers(localPortStr)
	if err != nil {
		return err
	}

	remotePorts, err := util.ParseRangeNumbers(remotePortStr)
	if err != nil {
		return err
	}

	if len(localPorts) != len(remotePorts) {
		return fmt.Errorf("local ports number should be same with remote ports number")
	}

	if len(localPorts) == 0 {
		return fmt.Errorf("local_port and remote_port is necessary")
	}

	// Templates
	prefix := strings.TrimSpace(strings.TrimPrefix(section.Name(), "range:"))

	for i := range localPorts {
		tmpname := fmt.Sprintf("%s_%d", prefix, i)

		tmpsection, err := f.NewSection(tmpname)
		if err != nil {
			return err
		}

		copySection(section, tmpsection)
		if _, err := tmpsection.NewKey("local_port", fmt.Sprintf("%d", localPorts[i])); err != nil {
			return fmt.Errorf("local_port new key in section error: %v", err)
		}
		if _, err := tmpsection.NewKey("remote_port", fmt.Sprintf("%d", remotePorts[i])); err != nil {

View on GitHub (pinned to 6c8a8d0a97)

Solutions

  1. Treat occurrence as a bug: report it upstream with the config values for local_port/remote_port
  2. Ensure both keys hold at least one valid port number as with errors 155/156
Defensive patterns

Strategy: validation

Prevention

When it happens

Trigger: Only conceivable if ParseRangeNumbers succeeded but produced an empty list — which its current implementation cannot do (any non-empty input either parses to >=1 number or errors). Expect to never see this error from real config files.

Common situations: None in practice; if it ever appears, suspect a modified/patched ParseRangeNumbers or a corrupted frp build.

Related errors


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