XTLS/Xray-core · error
reading source: unknown network type:
Error message
reading source: unknown network type:
What it means
In the inbound-source section of a mux frame, the network byte preceding the source address was neither TCP nor UDP. Address parsing succeeded but the transport type of the source destination cannot be determined, so unmarshalling aborts.
Source
Thrown at common/mux/frame.go:188
if b.Len() == 0 {
return nil // for heartbeat, etc.
}
network := TargetNetwork(b.Byte(0))
if network == 0 {
return nil // may be padding
}
b.Advance(1)
addr, port, err := addrParser.ReadAddressPort(nil, b)
if err != nil {
return errors.New("reading source: failed to parse address and port").Base(err)
}
switch network {
case TargetNetworkTCP:
f.Inbound.Source = net.TCPDestination(addr, port)
case TargetNetworkUDP:
f.Inbound.Source = net.UDPDestination(addr, port)
default:
return errors.New("reading source: unknown network type: ", network)
}
if b.Len() == 0 {
return nil
}
network = TargetNetwork(b.Byte(0))
if network == 0 {
return nil
}
b.Advance(1)
addr, port, err = addrParser.ReadAddressPort(nil, b)
if err != nil {
return errors.New("reading local: failed to parse address and port").Base(err)
}
switch network {
case TargetNetworkTCP:
f.Inbound.Local = net.TCPDestination(addr, port)
case TargetNetworkUDP:View on GitHub (pinned to 7d214f8b09)
Solutions
- Log the offending network value to distinguish fixed invalid values (protocol bug) from random ones (corruption).
- Pin matching Xray-core versions on both reverse-mux endpoints.
- In custom clients, write only TargetNetworkTCP/TargetNetworkUDP or 0 for padding in source/local blocks.
- Test over a clean transport to rule out middlebox interference.
Defensive patterns
Strategy: validation
Validate before calling
// When building frames, always use a defined source network value:
const (
pad = 0 // padding / absent
)
// write pad instead of an invented network byte when source is omitted
w.WriteByte(pad) Try / catch
if err := meta.Unmarshal(reader, true); err != nil {
if strings.Contains(err.Error(), "reading source: unknown network type") {
// peer encodes source blocks differently — abort, do not resync
}
return err
} Prevention
- Only emit 0/TCP/UDP bytes in source-address slots.
- Version-lock reverse-mux endpoints.
- Add round-trip unit tests for frames that include source and local blocks.
When it happens
Trigger: readSourceAndLocal path parses a network byte that is non-zero (so it is not treated as padding) yet not one of the two defined TargetNetwork values; typical with hand-built frames or corrupted reverse-mux streams.
Common situations: Custom reverse-mux clients writing invalid network bytes, or version drift between client and server on the source-address layout.
Related errors
- reading local: unknown network type:
- bridge tag is empty
- bridge domain is empty
- portal tag is empty
- portal domain is empty
AI-assisted analysis of XTLS/Xray-core@7d214f8b09 (2026-08-15).
Data as JSON: /api/errors/83f8d343beef5551.
Report an issue: GitHub.