XTLS/Xray-core · error

maxConnections cannot be specified together with maxConcurre

Error message

maxConnections cannot be specified together with maxConcurrency

What it means

SplitHTTPConfig.Build() forbids specifying both xmux.maxConnections and xmux.maxConcurrency with positive To values at transport_method.go:449-451. The two knobs are alternative mux sizing strategies — cap the number of connections, or cap concurrency per connection — and both together contradict each other. When neither is set (zero XmuxConfig), defaults are filled at lines 452-459 (maxConnections 3, hMaxRequestTimes 600-900, hMaxReusableSecs 1800-3000).

Source

Thrown at infra/conf/transport_method.go:450

			c.SeqKey = "X-Seq"
		}
	}

	if c.UplinkDataPlacement != splithttp.PlacementBody && c.UplinkDataKey == "" {
		switch c.UplinkDataPlacement {
		case splithttp.PlacementCookie:
			c.UplinkDataKey = "x_data"
		case splithttp.PlacementAuto, splithttp.PlacementHeader:
			c.UplinkDataKey = "X-Data"
		}
	}

	if c.ServerMaxHeaderBytes < 0 {
		return nil, errors.New("invalid negative value of maxHeaderBytes")
	}

	if c.Xmux.MaxConnections.To > 0 && c.Xmux.MaxConcurrency.To > 0 {
		return nil, errors.New("maxConnections cannot be specified together with maxConcurrency")
	}
	if c.Xmux == (XmuxConfig{}) {
		c.Xmux.MaxConnections.From = 3
		c.Xmux.MaxConnections.To = 3
		c.Xmux.HMaxRequestTimes.From = 600
		c.Xmux.HMaxRequestTimes.To = 900
		c.Xmux.HMaxReusableSecs.From = 1800
		c.Xmux.HMaxReusableSecs.To = 3000
	}

	config := &splithttp.Config{
		Host:                 c.Host,
		Path:                 c.Path,
		Mode:                 c.Mode,
		Headers:              c.Headers,
		XPaddingBytes:        newRangeConfig(c.XPaddingBytes),
		XPaddingObfsMode:     c.XPaddingObfsMode,
		XPaddingKey:          c.XPaddingKey,

View on GitHub (pinned to 7d214f8b09)

Solutions

  1. Keep only one strategy: either "maxConnections" or "maxConcurrency" inside "xmux"
  2. Or delete the whole "xmux" object to accept the built-in defaults

Example fix

// before
"xmux": { "maxConnections": { "from": 2, "to": 4 }, "maxConcurrency": { "from": 1, "to": 2 } }
// after
"xmux": { "maxConnections": { "from": 2, "to": 4 } }
Defensive patterns

Strategy: validation

Validate before calling

// Go: xmux strategies are mutually exclusive
if cfg.Xmux.MaxConnections.To > 0 && cfg.Xmux.MaxConcurrency.To > 0 {
	return errors.New("set only one of xmux.maxConnections / xmux.maxConcurrency")
}

Prevention

When it happens

Trigger: "xmux": {"maxConnections": {"from": 2, "to": 4}, "maxConcurrency": {"from": 1, "to": 2}} — both To > 0. Setting only one of them, or both with To <= 0, does not trigger (though To<=0 is itself suspect).

Common situations: Merging xmux tuning snippets from two different guides; editing an existing xmux block by appending instead of replacing fields.

Related errors


AI-assisted analysis of XTLS/Xray-core@7d214f8b09 (2026-08-15). Data as JSON: /api/errors/5dfb63aee5f5d602. Report an issue: GitHub.