v26.4.17: REALITY privateKey with base64url chars causes "pattern string does not conform to Letter-Digit-Hyphen (LDH) subset"

[Antoxa113]

Integrity requirements

• I have read all the comments in the issue template and ensured that this issue meet the requirements.
• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I provided the complete config and logs, rather than just providing the truncated parts based on my own judgment.
• I searched issues and did not find any similar issues.
• The problem can be successfully reproduced in the latest Release

Description

Bug Report

Version: v26.4.17
OS: Ubuntu 24, Linux amd64

Problem

After upgrading from v26.3.27 to v26.4.17, xray-core fails to start with REALITY inbound.

Error:
Failed to start: main: failed to create server > pattern string does not conform to Letter-Digit-Hyphen (LDH) subset

Cause

The REALITY privateKey is in standard base64url format which may contain underscore _ and dash - characters. These are valid base64url characters but do not conform to LDH subset, which apparently is now being validated in v26.4.17.

Example privateKey that triggers the bug:

aB3_xYz9KqmN2pLvWsRtUcHdEfGhJkMnOpQrStUvWxY

Steps to reproduce

1. Generate a REALITY keypair with xray x25519 (until you get a key containing _)
2. Use the privateKey in server config
3. Start xray v26.4.17 → fails with LDH error
4. Downgrade to v26.3.27 → works fine

Expected behavior

privateKey in base64url format should be accepted as before.

Workaround

Downgrade to v26.3.27.

Reproduction Method

Steps to reproduce

1. Generate a REALITY keypair with xray x25519 (until you get a key containing _)
2. Use the privateKey in server config
3. Start xray v26.4.17 → fails with LDH error
4. Downgrade to v26.3.27 → works fine

Client config

Not applicable

Server config

Not applicable

Client log

Not applicable

Server log

Not applicable

[sjhddh]

Took a careful look at this — I think the root cause is slightly different from what the report attributes it to, and wanted to share the trace before anyone chases the wrong file.

What the report claims

The REALITY privateKey (base64url, may contain _ / -) is being validated against LDH and rejected.

What the code actually shows

The REALITY privateKey never reaches strmatcher. In infra/conf/transport_internet.go#L850 it is decoded with base64.RawURLEncoding.DecodeString directly into config.PrivateKey ([]byte). From there it flows into reality.Config.PrivateKey in transport/internet/reality/config.go#L26 as raw bytes. There is no code path from privateKey to strmatcher.ToDomain.

The only caller of strmatcher.Domain.New (which invokes ToDomain) is common/geodata/domain_matcher.go#L170, reached through routing domain: rules, DNS hosts entries, geosite rules, etc.

The real regression

82624bc (geodata refactor, #5814) changed Type.New(Domain):

• v26.3.27: Type.New(Domain) returned domainMatcher(pattern) with no validation.
• v26.4.17: Type.New(Domain) now calls ToDomain(pattern) which rejects any character outside [a-z0-9.-] — including _.

So any existing routing/DNS config containing an underscore in a domain pattern (e.g. _sip._tcp.example.com, internal service names, anything under-validated before) now fails hard at startup, whereas before it just silently failed to match.

Could you share the full config?

My guess: there is a rule somewhere in the user's routing or dns config — not in the REALITY block — that contains _, and the switch from old privateKey to new privateKey coincided with another edit. With the full config (routing, dns) the exact offending rule can be pinpointed.

Proposed fix (if maintainers agree on direction)

Two options, both small:

A. Relax ToDomain to accept _ as well — matches real-world DNS usage (SRV records, internal hosts).

B. Remove the ToDomain call from Type.New(Domain) so it matches pre-refactor behavior; keep NewDomainPattern (the explicit strict API) unchanged. This is the cleanest separation — the strict API stays strict, the general API stays lenient.

I lean B since it preserves the intent of the two-API split (lenient vs strict) introduced in the refactor — the strict API (NewDomainPattern) stays strict, the general one stays lenient. Happy to open a PR either way once there's a steer on preferred direction (cc #5814).

[Meo597]

请提供完整的配置，可以隐去 key