XTLS/Xray-core · error
unknown type
Error message
unknown type
What it means
The JSON config loader's default switch branch: it was invoked with an input that is neither cmdarg.Arg (the string-slice of file paths Xray passes from the CLI) nor io.Reader. This is an API-misuse error for code that calls core.LoadConfig programmatically; the CLI itself never triggers it. There is no Base cause — the type is simply unsupported.
Source
Thrown at main/json/json.go:53
// This ensure even if the muti-json parser do not support a setting,
// It is still respected automatically for the first configure file
*cf = *c
continue
}
cf.Override(c, arg)
}
return cf.Build()
case io.Reader:
if serial.UseStrictJSON {
cfg, err := serial.DecodeJSONConfigStrict(v)
if err != nil {
return nil, err
}
return cfg.Build()
}
return serial.LoadJSONConfig(v)
default:
return nil, errors.New("unknown type")
}
},
}))
}
View on GitHub (pinned to 7d214f8b09)
Solutions
- Convert to cmdarg.Arg before calling: cmdarg.Arg is just []string, so wrap it
- If you have stream content, pass an io.Reader (bytes.NewReader(data)) instead
- Prefer the high-level core.LoadConfig(format, file, input) API, which handles accepted types
Example fix
// before
c, err := core.LoadConfig("json", nil, []string{"/etc/xray/config.json"}) // -> unknown type
// after
import "github.com/xtls/xray-core/main/cmdarg"
c, err := core.LoadConfig("json", nil, cmdarg.Arg{"/etc/xray/config.json"}) Defensive patterns
Strategy: type-guard
Validate before calling
if _, ok := input.(cmdarg.Arg); !ok {
if r, ok := input.(io.Reader); !ok { input = strings.NewReader(string(input.(string))) }
} Type guard
func isSupportedLoaderInput(v interface{}) bool {
switch v.(type) {
case cmdarg.Arg, io.Reader: return true
default: return false
}
} Try / catch
if !isSupportedLoaderInput(input) { return fmt.Errorf("pass cmdarg.Arg or io.Reader, got %T", input) } Prevention
- When embedding Xray, always convert paths with cmdarg.Arg{...}
- Wrap the loader call behind your own typed API
- Unit-test the programmatic config path in CI so type misuse is caught early
When it happens
Trigger: Calling the registered Loader (via core.LoadConfig("json", ...)) with e.g. a []string instead of cmdarg.Arg, a *os.File, a byte slice, or any other type.
Common situations: Embedding Xray as a library and passing a raw string or []string of paths; wrapping the loader with a custom front-end that reads config into memory and hands over the wrong type.
Related errors
- no valid FakeDNS config
- failed to get outbound handler with tag: ${tag}
- existing tag found: ${tag}
- bridge tag is empty
- bridge domain is empty
AI-assisted analysis of XTLS/Xray-core@7d214f8b09 (2026-08-15).
Data as JSON: /api/errors/b40875b35f7006fd.
Report an issue: GitHub.