2026-08-16

Some Personal Thoughts on Choosing a Reality Target

AI translation notice:
This English version was translated from the original Chinese article with AI assistance. The original Chinese version is the authoritative source; please refer to it if any wording is unclear.

Disclaimer:
This article applies to server-side Reality in Xray. Some of the information here may not apply to server-side Reality in Sing-box.
The Target suggestions in this article may also be unsuitable for large-scale proxy deployments, such as commercial proxy services.
This is a collection of personal observations, provided for reference only. Please comply with the laws and regulations in your area.
Please also keep the publication date in mind when reading.

In newer versions of Reality, the field is named Target; older versions called it Dest. To match the newer terminology, it is recommended to use Target in server-side Reality configurations.
Every mention of Target in this article uses the newer Reality terminology.

Why Target selection matters

For newcomers, choosing a Target can be a headache. Many guides recommend a general-purpose approach for beginners.
That is, using well-known sites such as www.apple.com, www.bing.com, or www.microsoft.com as camouflage. This general approach certainly works: it is ready to use and requires little thought.
Well-known Targets naturally tend to have high traffic and stable handshakes.

For me personally, however, this may not be the best solution. Reality does not resolve questions of ASN and IP-range attribution.
If Microsoft is used as a Target, the server borrows Microsoft's handshake as camouflage.
Yet the Target's IP ranges and ASN are publicly searchable. To an observer, a Microsoft handshake appearing on an unknown ASN and IP range may look unusual.
Put another way, Microsoft is unlikely to deploy its service on an unknown VPS.
At the time of writing, I have not observed large-scale attempts to correlate Reality characteristics through ASNs and IP ranges.

To reduce statistical fingerprints as much as possible, it may be better to look for other sites that meet the requirements and avoid being implicated by association.

Target requirements and considerations

1. The Target supports TLS 1.3.
2. The Target is reachable directly, is not blocked, and provides a stable handshake connection.
3. X25519MLKEM768 or X25519 is recommended for the key-exchange algorithm.
4. It may be a CDN-backed site or an independently hosted site. (If you can find one.)
5. The site type is unrestricted: it may be a corporate site, game site, animation site, manga site, movie site, shopping site, and so on.
6. The site should have a genuine business and should not involve sensitive content, including adult or political content.
7. A Target may be a subdomain; subdomains of large sites are recommended.
8. A subdomain does not have to show content when opened in a browser. For example, api.xxx.com, cdn.xxx.com, and update.xxx.com can all be Targets, as long as the handshake is stable.
9. The site should have some recognition and ideally real visitors; it should not be too niche.
10. Try to align regions. For example, use a Japanese site for a Japanese server and a US site for a US server.
11. If the server has only IPv6, it is best to choose a Target that supports IPv6.

I will explain these points one by one below.

The Target supports TLS 1.3.

Reality's handshake depends on TLS 1.3, so the Target must support TLS 1.3.
(Do not use TLS 1.2. Even if you find a TLS 1.2 Target, do not use it.)

I will introduce several quick ways to determine whether a Target supports TLS 1.3, on mobile, desktop, and the server.

First, on mobile:

Install Edge or Chrome on your phone. Chrome is used as the example below.
Open the browser, enter the domain name, and visit the site.

Open the lock icon in the address bar and select the security tab to see the information directly.

You can also see the key-exchange algorithm below.
The process is the same in Edge on mobile.
After visiting the site, open the lock icon in the address bar to view it directly, as shown below:

Then, on desktop:

Open the Target site in Edge. Press F12 to open Developer Tools, or right-click and choose Inspect. Make sure DevTools is open, as shown below:

Click the plus sign on the toolbar to add the Security tab.

After switching to the Security tab, be sure to refresh the page. Press F5 or right-click, then select the main origin to see the TLS version and key-exchange algorithm used by the current connection.

In Chrome, the procedure is as follows:

On the server:

Make sure Xray is installed on your server.
I use Termius as my SSH client, but you can use any other SSH client to connect to the server.
Use the following command to test a Target site's TLS version and key-exchange algorithm directly:

xray tls ping Target

Replace Target with the site you want to test.

For example:

The Target can be reached directly, is not blocked, and has a stable handshake connection.

Make sure the Target used by Reality is not subject to SNI blocking or other blocking. Using an interfered-with site can cause Reality's handshake to fail. Therefore, a stable site is a good Target choice. Some interfered-with Targets, such as store.steampowered.com and github.com, have very high traffic and recognition. However, GitHub and Steam connections are not especially stable, so I do not recommend them as Targets. Ideally, choose a site that also opens quickly from your local network. A site that takes a very long time to load is not ideal either.

X25519MLKEM768 or X25519 is recommended for the key-exchange algorithm.

Next, regarding the Target site's key-exchange algorithm: in general, TLS 1.3 sites use X25519, while CDN-backed sites commonly use X25519MLKEM768.
Where possible, I recommend the latter. It is a hybrid post-quantum key exchange and offers higher security. This is not mandatory, however. X25519 is also acceptable, and current X25519-based key exchange remains sufficiently secure; quantum computers cannot yet break it. Are there sites that use neither X25519 nor X25519MLKEM768 for TLS 1.3 key exchange?
Yes, but they are uncommon.

At present, the possible impact of using other key-exchange algorithms with Reality is unclear. Other key-exchange algorithms are not common in TLS 1.3, however. I looked at nearly 70 sites as potential Targets, and most of them used either X25519 or X25519MLKEM768.

A Target may be CDN-backed; an independently hosted site is also fine.

At least for now, most well-known sites use CDNs, while independently hosted sites are relatively uncommon. A CDN-backed site is fine as a Target. There is some debate about using Cloudflare CDN sites with Reality. At present, it is not a major issue for personal use. If this concerns you, you can use an Amazon site or another CDN-backed site.

The site type is unrestricted: it may be a corporate site, game site, animation site, manga site, movie site, and so on.

You are not limited to the types listed above; choose according to your preference. Any site that meets Reality's requirements is acceptable. Within those limits, you can choose freely.

The site should have a genuine business and should not involve sensitive content, including adult or political content.

In theory, a site with genuine business is less likely to be blocked. Similarly, a site with adult or other sensitive content may be blocked. To avoid being affected by association, try to choose a site with compliant business activity as the Target.

A Target may be a subdomain; subdomains of large sites are recommended.

This may surprise people who are new to Reality. In fact, a large site can contain many subdomains. As long as a subdomain supports TLS 1.3, it can also be used as a Target. I personally lean toward subdomains because their traffic is larger and more varied, with more realistic traffic characteristics.

A subdomain does not have to show content when opened in a browser. For example, api.xxx.com, cdn.xxx.com, and update.xxx.com can all be Targets, as long as the handshake is stable.

In fact, Reality does not require the Target to display content in a browser. Even if a CDN subdomain used as a Target returns a 404 in the browser, it can still be suitable as long as it meets Reality's requirements. In my personal experience, this works reasonably well.

The site should have some recognition and ideally real visitors; it should not be too niche.

This point still needs further study. My current observation is that using an overly niche site may lead to Reality being targeted. Typical symptoms are a connection that works but cannot achieve normal speed, or unexpectedly slow performance. To improve stability, choosing a site with a certain amount of real traffic is the best option.

Try to align regions. For example, use a Japanese site for a Japanese server and a US site for a US server.

This is not mandatory. If the site is CDN-backed, your handshake will often be completed by an edge node, and CDN nodes may be distributed worldwide. Regional alignment can improve the camouflage effect, though the impact appears limited at present.

If the server has only IPv6, it is best to choose a Target that supports IPv6.

This point deserves more explanation. If your server is IPv6 ONLY, it has no IPv4 address. You should therefore find a site that supports IPv6. If the site does not support IPv6, Reality's handshake will fail and the connection cannot be established. The frustrating part is that, for a Japanese server, finding an IPv6-capable Japanese site as a Target can be difficult. Most Japanese sites support only IPv4. Even CDN-backed sites may expose only IPv4.
In this situation, there are two ways to help Reality on an IPv6-only server complete the handshake.

The first is WARP CLI. By obtaining a WARP IPv4 address from Cloudflare, you gain an IPv4 address. Reality can then use Cloudflare's edge network to complete the handshake with the Target. This is the first approach. Incidentally, the IPv4 address assigned by Cloudflare is outbound-only, so it cannot be used for SSH. The second approach is to use a public NAT64 server to convert IPv4 access to a special IPv6 address. In essence, this is also a relay, and it is slower than WARP.

A recommended public NAT64 server is:
https://nat64.net/

However, both approaches may involve some risk.

This raises a question:

How can a Target site that has only an IPv4 DNS A record suddenly receive IPv6 access through an AAAA record? Your server accesses it over IPv6, but the Target itself has no IPv6 AAAA record. In theory, if the GFW knew that the Target had no AAAA record, it might identify Reality based on this characteristic. That said, this alone may not be enough to determine that a server is a proxy; NAT64 traffic also exists on the Internet. This cannot currently be verified. Because the handshake happens overseas, the GFW cannot observe it. There is no research showing that the GFW attempts to query a Target site's DNS records. So far, this approach remains effective.

I recommend a dual-stack IPv4 + IPv6 site as a Target.

The situation above applies only when an IPv6-only server uses an IPv4-only Target.

When the server has IPv4, Reality completes the handshake with the Target over IPv4. Even NAT IPv4 can complete the handshake. Even if the IPv4 address is blocked locally, Reality can complete the handshake as long as the server can reach the Target from overseas, so this issue is not a concern.

What I most want to say at the end is this: there is no single best Target solution. Everyone's choice can be different. Just find what suits you best. I will not recommend any particular site as the best or most convincing Target. Blocking is often caused by multiple factors together. Because the GFW is a black box, we cannot directly conclude that a Target caused a block. The well-known Targets mentioned in this article are examples only, not recommendations.

Everything above is only a personal discussion of Reality.

The information in this article may not fully apply to censorship conditions in the reader's region.

Tools mentioned in this article: