Please check the server settings first in v2rayN

People search for this message with "v2rayNG" in the query, but the text comes from v2rayN, the desktop client for Windows, macOS and Linux. v2rayNG on Android has its own, shorter messages for the same situations. This post explains when each app shows them, which parts of a share link cause them, and how to check a link outside the app.

I read the source of the current releases on 10 November 2026: v2rayN 7.25.6 (11 October 2026) and v2rayNG 2.3.15 (1 November 2026). For older wording I went through the v2rayN commit history.

What does "please check the server settings first" mean?

It means v2rayN refused to build a config for the core. Either there is no profile at all, or the selected profile failed a validity check. The app never tried to reach the server, so the server itself can be perfectly healthy.

The wording has changed twice, which is why you will see three versions of it in screenshots and forum posts:

v2rayN version	English text	Chinese text
Up to 7.10.5 (March 2025)	Please check the server settings first.	请先检查服务器设置
7.11.1 (April 2025) to 7.20	Please check the Configuration settings first.	请先检查配置文件设置
7.21.1 (April 2026) and later	Invalid configuration, please check or reselect	配置项无效，请检查或重新选择

All three are the same message (the resource key is CheckServerSettings). In 7.25.6 it appears in four places:

1. When you start or reload the core and v2rayN has no profile to use. If the selected profile was deleted, the app falls back to the first one in the list, so in practice this means the list is empty.
2. When the profile it is about to start fails the check described below.
3. When it builds a config for a speed or delay test and the profile fails the same check.
4. In the status bar, in place of the running server's name, when there is no profile.

v2rayNG does not use this text. I could not find it in any v2rayNG release I checked, from 1.2.0 to 2.3.15. When you start v2rayNG with nothing selected, it says Add a profile in the app before using this feature. (初次使用此功能请先用 APP 添加配置). When the selected profile cannot be read, or its server address is neither a valid host name nor an IP address, it says Invalid config (无效的配置). Those are the v2rayNG equivalents, and the fixes below apply to them too.

Is the link broken or just not imported?

Look at the server list first. If it is empty, the import failed, and the message is only telling you there is nothing to start.

In v2rayN, Import Share Links from clipboard reports the result. Success reads "1 Configurations have been imported from clipboard" (with the count). Failure reads Operation failed, please check and retry, and that is the message to fix first: the link did not parse, so no profile exists.

The usual reasons an import fails:

• Extra text around the link. Messengers add a name, a line break or a space in the middle. Paste it into a plain text editor first and make sure it is one line that starts with vless://, vmess://, trojan://, ss:// or hy2://.
• A cut-off link. Some chat apps shorten long messages, and a vmess:// link is one long base64 string. If the end is missing, it will not decode.
• A subscription URL pasted as a link. An https:// address is a subscription, not a server. Add it under subscription settings and update it, and the servers appear in the list.
• A partial QR scan. Scan again closer, or ask for the text version.

If the list does have a profile and you still see the message, the profile was imported but fails the check. That is the next section.

Which fields in a vless:// or vmess:// link cause it?

In v2rayN 7.25.6, a profile fails the check if any of these is true. Custom configs (a full JSON file you imported) skip the check.

Field	The rule in v2rayN 7.25.6	A value that fails
Address	Must not be empty	vless://id@:443
Port	Must be from 1 to 65535	0, 70000, or no port where the app needs one
VMess id	Must be a valid UUID	abc123, or a UUID with a character missing
VLESS user ID	Must not be empty; if it is not a UUID, it may be at most 30 characters	A 36-character ID with a typo, so it is no longer a UUID and is too long
VLESS flow	Must be empty, xtls-rprx-vision or xtls-rprx-vision-udp443	xtls-rprx-direct, xtls-rprx-vision (trailing space), vision
REALITY pbk	Required when security=reality (VLESS and Trojan)	pbk= left empty, or the parameter missing
Shadowsocks password	Must not be empty	ss:// link with only a method
Shadowsocks method	Must be one the app lists	A method name with a typo

Two of these trip people up more than the rest. The first is an old flow. Links made years ago may still carry xtls-rprx-direct or xtls-rprx-splice, which Xray removed long ago. The second is a REALITY link that lost its pbk, often because someone copied it from a panel with the public key field still empty.

Here is a REALITY link that fails, because pbk is missing (split over several lines to read; a real link is one line):

vless://aafd62da-d5aa-406c-985d-17cc48f142fd@vpn.example.com:443
  ?type=tcp&encryption=none&security=reality
  &sni=www.example.com&fp=chrome&sid=48047fad
  &flow=xtls-rprx-vision
  #fra-01

Add &pbk= with the server's public key and it passes. The full list of VLESS fields and what each one means is in the VLESS key checker guide.

A vmess:// link is different: after the scheme it is base64-encoded JSON. The fields v2rayN checks are add (address), port and id:

{
  "v": "2",
  "ps": "fra-01",
  "add": "vpn.example.com",
  "port": "443",
  "id": "b831381d-6324-4d53-ad4f-8cda48b30811",
  "aid": "0",
  "net": "ws",
  "path": "/ray",
  "tls": "tls",
  "sni": "vpn.example.com"
}

If add is empty, port is missing or id is not a UUID, the profile fails. Older releases checked less. In 7.10.5, for example, the sing-box config path only checked that a profile was selected and that its port was above 0, so an old version might accept a link that a new one rejects.

How do I check the link is valid outside the app?

Decode it and look at each field, or paste it into a tester that runs a real client. Decoding catches a broken link. Only a real connection proves it works.

For a vless:// link, Python's standard library is enough. It prints the user ID, host, port and every parameter, and it raises an error if the port is not a number:

python3 -c 'import sys, urllib.parse as u, uuid
p = u.urlsplit(sys.argv[1])
print("id:", p.username, "| host:", p.hostname, "| port:", p.port)
for k, v in u.parse_qs(p.query).items(): print(" ", k, "=", v[0])
uuid.UUID(p.username); print("id is a valid UUID")' 'vless://aafd62da-d5aa-406c-985d-17cc48f142fd@vpn.example.com:443?type=tcp&security=reality&pbk=DVm-D2KuvBWxtDYfTW6rxE&sid=48047fad#fra-01'

If the last line raises ValueError: badly formed hexadecimal UUID string, the user ID is not a UUID. That is fine for a short VLESS ID, but not for VMess.

For a vmess:// link, decode the part after vmess:// and read the JSON:

echo 'eyJ2IjoiMiIsImFkZCI6InZwbi5leGFtcGxlLmNvbSJ9' | base64 -d

Some links use the URL-safe base64 alphabet (- and _ instead of + and /) or drop the = padding. If base64 -d complains, swap those characters back and add = until the length is a multiple of 4.

To test the link end to end, paste it into the free TunnelHQ tester. It runs a real Xray client against the server and sends a request through the tunnel, five tests a day with no account. When the link itself is the problem, it says so instead of reporting a dead server:

• If it cannot find a host in the link, the result reads The test failed to run (422), with "Could not determine the target host from that config".
• If the host does not resolve, it names the host and asks you to check the address for a typo.
• If the checker cannot parse the rest of the link (no user ID, or no numeric port), the result is VLESS handshake failed, and under "What the checker saw" it shows Config error: cannot parse xray config/URI.

The tester does not check the UUID format itself. It leaves that to the server, which answers the real question: does this server accept this user?

What if the settings are right and it still fails?

Then you are past this message. The profile is valid, the core starts, and the problem is somewhere between your device and the server, or on the server itself.

A few steps narrow it down:

1. Run the real delay test. If it shows a time, traffic goes through the server. If it shows -1, no good answer came back. What the real delay test measures explains what each result means in v2rayN and v2rayNG.
2. Read the core log. In v2rayN the log panel shows Xray's own error once the core is running. Lines such as invalid request user id on the server side, or failed to read response version on the client side, point at the user ID. The VLESS key checker guide lists these messages layer by layer.
3. Check for an old insecure link. Xray-core removed allowInsecure in v26.2.6. v2rayNG now warns that a node with an unencrypted or unverified connection "cannot be connected via Xray core version 26.2.6+". The fix is on the server side: TLS with a real certificate, or a pinned certificate hash in the link.
4. Test from somewhere else. A link that works from one network and not another usually means something on the path is blocking the IP address, the port or the SNI.

If you run the servers rather than use them, the same check is worth running on a schedule, so you hear about a broken link before your users do. VLESS monitoring and VMess monitoring describe how TunnelHQ does that from outside, with a real handshake every few minutes.