What Does a REALITY Short ID Do?

A REALITY short ID is a small client-selected value that must match one entry in the server's configured shortIds list. It helps the REALITY server decide whether an incoming handshake carries an accepted configuration value. It is only one check in the REALITY authentication path: a matching short ID does not replace the server public key, the permitted server name, compatible software, or the later VLESS user ID.［1］

The complete VPN guide maps the wider connection path. This article stays at the short-ID field boundary so that a formatting or selection error is not confused with every other VLESS or REALITY setting.

Key Takeaways

• The client uses singular shortId; the server publishes an accepted shortIds list.
• The client value must equal one configured entry after applying the documented hexadecimal format.
• A short ID can contain at most 16 hexadecimal characters and must have an even number of characters.
• An empty value works only when the server deliberately includes an empty entry.
• Treat short IDs as sensitive configuration metadata even though they are not encryption keys.

What is a REALITY short ID?

Project X defines shortIds on the REALITY server as a list used to distinguish different clients. The client has one shortId, and that value must be one of the server entries.［1］ The relationship is set membership, not negotiation: the client does not send a collection and ask the server to choose.

The word “ID” can be misleading because the field does not name a human account. It is closer to a compact selector inside the REALITY authentication configuration. Several authorized profiles can use distinct entries, allowing an operator to separate configuration groups or rotate one value without changing every profile at once. The exact operational grouping is an administrator choice, not a protocol guarantee.

Figure key: 1 is the single client shortId; 2 is membership checking against the server shortIds[] list and its documented hexadecimal format; 3 is the later REALITY authentication path. The arrows describe configuration relationships, not literal packet fields or a complete handshake timeline.

How does shortId match shortIds?

The comparison is exact after the hexadecimal text is decoded into its effective eight-byte value. If the server lists 6ba85179e30d4fc2, a client configured with different non-zero digits, an inserted separator, or an odd number of characters does not refer to that entry. Friendly profile names and JSON comments are not substitutes for the actual parsed value.

The official configuration permits zero to sixteen hexadecimal characters, with an even number of characters. The core places the decoded bytes at the beginning of an eight-byte value and pads the remaining bytes with trailing zeroes. For example, aa1234 normalizes to the same value as aa12340000000000; adding zeroes at the front changes the value. The server list can contain an empty string, and a client can use an empty value only when that entry is actually accepted by the server.［1］ “Optional in one example” therefore does not mean “ignored by every server.”

Check	Client side	Server side	Meaning of failure
Field name	shortId	shortIds	Singular/plural placement may be wrong
Type	One string	List of strings	Import or schema error
Alphabet	Hexadecimal	Hexadecimal	Value cannot meet the documented format
Length	Even, at most 16 characters	Same per entry	Entry is malformed or copied incorrectly
Membership	One normalized value	Same normalized server entry	REALITY authentication cannot use that selector
Empty value	Empty client selection	Empty entry present	Empty is rejected when not explicitly accepted

Do not silently “repair” an odd-length value by guessing where a zero belongs. Obtain the intended value from the authorized configuration source. Only the documented trailing-zero normalization preserves a shorter value; adding leading zeroes or inventing digits during troubleshooting creates a different entry.

What does a mismatch actually prove?

A mismatch proves only that this short-ID check cannot succeed for that attempt. Depending on the implementation and configuration, the client may see an early disconnect or a generic handshake failure, while traffic that fails REALITY authentication may follow the configured target or fallback behavior.［1］ The visible symptom is not guaranteed to say “short ID mismatch.”

It does not prove that the network blocked REALITY, that the server public key is wrong, or that the VLESS UUID was rejected. Those checks occupy different layers. A server may be reachable and still reject the short ID. Conversely, correcting the short ID may reveal a later public-key, server-name, UUID, flow, routing, or DNS problem.

Use the first differing stage as evidence. If the intended listener sees the connection and the authorized key and server-name values are already verified, comparing the short ID becomes reasonable. If the server sees no connection, changing the short ID cannot repair DNS, address, port, firewall, or routing failures.

How is it different from a UUID or key?

The VLESS UUID identifies an allowed VLESS user at the proxy-protocol layer.［3］ The REALITY client public-key material corresponds to the server's private key and participates in the outer authentication design. The short ID is another REALITY configuration selector. Combining all three under “password” makes rotation and diagnosis unsafe.

Value	Layer	Primary question	Do not infer
REALITY shortId	REALITY	Is this selector in shortIds?	Human identity or encryption strength
REALITY password	REALITY client config	Does this public-key material correspond to the server key?	Website certificate ownership
VLESS id / UUID	VLESS	Is this proxy user allowed?	Device ownership or REALITY success
serverName	TLS-facing REALITY config	Is this name permitted and coherent with the target?	User authorization
flow	VLESS/XTLS configuration	Which supported flow algorithm is selected?	QoS or route choice

VLESS, REALITY, and XTLS Vision explains these layer boundaries. Keeping separate labels in an inventory is more useful than storing a single opaque “profile credential.”

How should short IDs be assigned and rotated?

Start with an owner and an inventory. Record which authorized configuration group receives each entry, when it was issued, which server list contains it, and when it should be removed. Do not publish actual values in a general runbook. A label such as “mobile-test-2026-09” belongs in the inventory; the literal short ID belongs in the protected configuration system.

For rotation, add the new server entry first, deploy and verify that exact list, update the intended clients through an authenticated channel, then remove the old entry after the agreed overlap. This order avoids an unnecessary outage. It also preserves a rollback point while clients are being updated.

Distinct values can narrow which configuration group is stale, but they are not a complete identity or revocation system.［2］ If several people share a copied profile, a distinct short ID cannot prove which person made a request. Use the VLESS user inventory, access controls, and operational logs according to policy rather than assigning the short ID a role it does not have.

Minimize retention in logs. A partial fingerprint, configuration revision, and result category are normally enough for correlation. Do not place full profiles, UUIDs, private keys, or short IDs in screenshots, public tickets, shell history, or analytics events.

How do you diagnose a REALITY short ID failure?

Freeze one attempt: timestamp with time zone, client and server versions, configuration revision, endpoint, and exact error category. Confirm that the client reached the intended listener. Then compare authorized representations of the parsed client shortId and server shortIds, not two screenshots that may hide or normalize the field.

Check the field name and location, the string type, hexadecimal characters, even length, and exact membership. Confirm whether an empty entry is intentional. If a management system generated the value, inspect its exported configuration rather than assuming the UI label equals the transmitted setting.

Next verify the neighboring REALITY fields independently: the current client password public-key material, the selected serverName, target-related configuration, clock, fingerprint option, and version compatibility. Why the REALITY target matters covers the target contract; the layered failure checklist shows when to move to VLESS and routing.

Change one variable per hypothesis. If adding the exact authorized short ID moves the failure to a later stage, record that transition and finish the later diagnosis. If nothing changes, restore the baseline rather than cycling through random values. Repeated guessing can trigger controls, lose the original evidence, and distribute more sensitive configuration.

What if you would rather not manage short IDs?

Some readers maintain shortIds lists only to keep a private connection working. For that goal, AethoVPN offers a documented workflow of a different kind: select a location or the smart-recommended node in the app and connect, with server status shown by load colour, rather than generating, distributing, and rotating short IDs. The same client also works as a control test: connect it on the device and network where your REALITY client fails, and a working session there shows that the device and network can carry an encrypted connection, so your own shortIds entry and client profile move up the list of suspects. Because the official site names no protocol for AethoVPN, the comparison says nothing about how short IDs are handled, and none of the fields discussed here is a product setting. Create an account with your email for that managed comparison, and never invent a short ID for your own server.

Summary

• A client shortId must normalize to the same eight-byte value as one server shortIds entry.
• Valid values use an even number of hexadecimal characters and no more than sixteen characters.
• Empty is a deliberate accepted entry, not a universal wildcard.
• A mismatch identifies one failed REALITY check, not the condition of every later layer.
• Inventory, rotate, compare, and redact short IDs separately from public keys and VLESS UUIDs.

FAQ

Is a REALITY short ID secret?

It is not a private encryption key, but it is sensitive configuration metadata used in authentication. Avoid publishing it or placing it in logs and screenshots.

Can two clients use the same short ID?

The configuration can allow that, but the value then cannot distinguish those clients by itself. Use an intentional inventory and separate VLESS users when accountability or revocation requires it.

Does the short ID need exactly sixteen characters?

No. The documented maximum is sixteen hexadecimal characters and the length must be even. The core pads shorter decoded values with trailing zeroes to eight bytes.

Is an empty short ID always accepted?

No. It works only when the server's shortIds list includes an empty entry and the rest of the configuration is valid.

Will a mismatch produce a clear error message?

Not necessarily. It may appear as a generic handshake rejection or early disconnect, so correlate both authorized endpoints and verify one field at a time.

Is the short ID the same as the VLESS UUID?

No. The short ID belongs to REALITY configuration matching; the UUID identifies an allowed user in the VLESS layer.

Should I change the short ID when a site will not load?

Only when evidence points to the REALITY authentication stage. A site failure after an authenticated session is more likely to involve local capture, DNS, routing, server forwarding, or the destination.

Disclaimer: This article is general technical information for authorized configuration and troubleshooting. Do not guess credentials, expose profiles, or bypass a network owner's policy.

Sources:

1. Project X, "REALITY configuration": https://xtls.github.io/en/config/transports/reality.html
2. XTLS, "REALITY README": https://github.com/XTLS/REALITY/blob/main/README.en.md
3. Project X, "VLESS protocol": https://xtls.github.io/en/development/protocols/vless.html

Sources checked 12 September 2026.

---

Related Articles:

• Map the complete VPN path
• Separate VLESS, REALITY, and XTLS Vision
• Troubleshoot a failed VLESS Reality connection
• Understand the REALITY target contract
• Diagnose a REALITY public-key mismatch