1. Break Configuration into Four Layers
A server entry in a client usually combines a proxy protocol, an underlying transport, a security layer, and a local connection method. Each serves a different purpose, so the protocol name shown in a list does not tell you everything the configuration can do. The proxy protocol handles authentication, destination addresses, and data forwarding between client and server. The transport carries that data over a connection. The security layer encrypts the connection and verifies identity. The local connection method determines which apps can send requests through the client. Troubleshoot one layer at a time to find the right setting to change.
The Protocol Name Is Only Part of the Setup
VLESS, for example, identifies the proxy protocol, but says nothing about whether TLS or REALITY is used, which transport is configured, or whether the server requires a specific flow. Two VLESS configurations may need different core features. VMess can also use different transports, while Shadowsocks requires you to check the encryption method. When editing a server, confirm the protocol first, then check the address, port, and authentication fields, followed by the transport and security settings. Do not change the protocol name in a dropdown at random: the client cannot turn the remote service into a different protocol that way.
The server address and server name are different fields. The server address identifies where to connect, usually a domain or IP address. The TLS server name is sent during the handshake and is used to verify the certificate identity. They may match, but some deployments require different values. If you replace the server address with an IP address and then clear the server name, certificate verification that used to work may fail. The server port is the remote listening port; do not confuse it with the local listening port. The client's local port is where apps on your device connect. Changing it does not affect the remote server's listening port.
Check Local Access Separately from the Remote Protocol
In v2rayN, the system proxy setting tells apps that honor system proxy settings to send requests to the local client. It is not the remote protocol, and not every program is guaranteed to use it. TUN mode is a separate connection method that typically involves a virtual network interface, permissions, and routing. Android clients use system VPN permission to create a local connection path, but the VPN icon only indicates that the local service is running; it does not prove remote authentication succeeded. Check the logs and test with the app you intend to use.
Routing rules apply after a request enters the client. They can send a domain, address, or port through a proxy, direct, or blocked outbound route, but they cannot fix an incorrect server password. DNS resolution may happen in the app, the operating system, the local client, or the remote connection, depending on the access and DNS settings. If only some domains fail to load, first determine whether DNS resolution failed, the request took the wrong outbound route, or the remote connection failed. Switching every protocol at once makes the original problem harder to reproduce.
| Layer | Common Fields | What to Check |
|---|---|---|
| Proxy protocol | Type, UUID, password, encryption method | Must match the server protocol and authentication requirements |
| Transport | TCP, WebSocket, gRPC, path | Must match the server's transport and listener |
| Security layer | TLS, REALITY, server name | Identity details and security parameters must match |
| Local access | System proxy, TUN, app filtering | Requests from the target apps must enter through the right path |
Keep a Record of the Settings You Check
For troubleshooting, record non-sensitive details such as the protocol, address, port, transport, security layer, server name, and core, along with whether you are using the system proxy or another access method. Store UUIDs, passwords, and subscription URLs separately; do not include them in public screenshots. Save a copy of the original configuration, then change one field at a time. If the logs report that the local port cannot be bound, resolve the port conflict first. If the certificate name does not match, check the server name and certificate. If authentication is rejected, check the credentials and protocol. Fixing the layer named in the error is more reliable than guessing based on the client name.
2. VMess, VLESS, Trojan, and Shadowsocks Compared
Choose a protocol only if the server actually offers it. Client support for a protocol does not mean every server can accept it. The comparison below focuses on each protocol's role and configuration boundaries, not on speed rankings that ignore device and network conditions. Protocol overhead is only one part of a complete connection; network quality, transport, and server implementation can all affect the experience. If your current subscription is stable, importing it correctly and verifying the connection is more useful than moving every configuration to a protocol with a newer-sounding name.
VMess: Authentication and Encryption in One Protocol
VMess originated as an early protocol design in Project V and handles tasks such as authentication and data protection. When using it today, check that the client and server support the current authentication mechanisms rather than copying historical settings from an old guide. Some legacy configurations include extra identity fields whose meaning varies between implementations and versions. If authentication fails after import, check the server's documentation, the UUID, and the time on both devices. Do not treat numbers from an old article as universal fixes. A significantly incorrect system clock can also affect authentication or the security handshake.
VMess is widely supported by existing deployments and subscription tools, so it remains a practical choice for configurations that are already working and maintained. There is no need to change cores just because of the protocol name, but both ends must support the chosen transport. Distinguish the protocol's internal encryption settings from outer TLS: the names may sound similar, but they control different things. If the configuration specifies an encryption method, use that exact value. Do not change the internal field arbitrarily just because TLS is enabled. The more legacy compatibility fields a configuration has, the more useful it is to keep the original import for comparison.
VLESS: A Lean Proxy Layer That Relies on External Protection
VLESS keeps the proxy layer simpler and, unlike VMess, does not provide data encryption as part of its basic design. It is commonly paired with a security layer such as TLS or REALITY. A lightweight design does not mean authentication can be ignored, or that plaintext is suitable for an untrusted connection. If the client's encryption field is set to none, interpret it together with the outer security settings. This may be required by the protocol; it does not mean you should disable protection for the entire connection. Before choosing VLESS, confirm the complete combination offered by the server.
VLESS configurations often include a flow field. Flow is not a performance toggle to enable at will; it is protocol behavior tied to specific implementations and transport combinations. Do not add it unless the server requires it, and do not omit it when required. If the subscription creates a server entry but the client reports an unsupported flow when starting, check the selected core and its feature support before changing the UUID. For a subscription you already use, preserving the fields specified by the server matters more than making every configuration look the same.
Trojan and Shadowsocks: Different Authentication Fields
Typical Trojan deployments use password authentication and rely on TLS to protect the connection. Check both the password and certificate verification settings. Even with the correct password, a wrong server name can cause the handshake to fail before authentication. The configuration may look short, but that does not make the security layer optional. If the server uses an additional transport wrapper, the client must have the matching fields. Pasting a Trojan password into a UUID field or changing only the prefix of a different protocol's share link will not create a valid configuration.
Shadowsocks is often shortened to SS. Its key settings include the server address, port, password, and encryption method. Encryption methods are not interchangeable; for newer method families in particular, confirm that both implementations support the same one. Some configurations also require extra encapsulation parameters, so keeping only the address and password may not be enough. The design is generally simple, but resource use depends on the cipher, processor support, and forwarding path. Do not keep choosing an older method just because a guide calls it “the most compatible.” Use one explicitly supported by the current server and core.
In practice, check modern implementation compatibility and system time for an existing VMess configuration; check the security layer and flow for VLESS; check both the password and TLS identity for Trojan; and confirm the exact encryption method for SS. Compare performance only when the server offers multiple endpoints that can be tested fairly. Keep the region, access method, and time of day as similar as possible so differences between servers are not mistaken for protocol differences.
3. Transport, TLS, and REALITY: Where the Settings Apply
Beyond the proxy protocol, the transport and security layer often determine whether a configuration can connect. Transport settings describe how data is carried; security settings describe how the connection verifies identity and protects data. They can be combined, but not arbitrarily. The client must match the transport and security options chosen by the server; extra options in a client dropdown only indicate that the client can configure them. When reading subscription documentation, record the protocol, transport, and security layer as a complete combination. A single name alone is not a complete answer.
TCP, WebSocket, and gRPC
With TCP as the transport, the connection path is relatively direct, but establishing a connection may still require a TCP handshake, a security handshake, and proxy authentication. WebSocket carries bidirectional data after an HTTP handshake, and often requires you to check the path and host information in the request headers. Path capitalization, the leading slash, and the server's reverse proxy rules can all affect matching. If the handshake is rejected, check not only the protocol password but also whether the request reached the right endpoint. A regular webpage in the response does not mean proxy authentication succeeded.
gRPC is based on HTTP/2, and its configuration often includes a service name. Do not copy a WebSocket path into that field. The front-end service must support the connection type, and idle timeouts in the path can affect long-lived connections. A transport that works well on one route may not suit another deployment. For an existing service, use the transport it explicitly provides. If you manage the server, evaluate the intermediate proxy, connection handling, and application type. Extra encapsulation usually adds processing steps, but whether the overhead is noticeable must be measured.
TLS: Certificate Names Matter More Than the On/Off Switch
TLS is more than a toggle. The client needs to verify the certificate chain, validity period, and target name; some configurations also specify application-layer protocol negotiation parameters. The server name is usually sent as a name indication during the handshake and is related to certificate identity verification. The host name in transport request headers serves a different layer. Even if a deployment happens to use the same text in both fields, they are not always interchangeable. After changing an address, moving a domain, or modifying a reverse proxy, check each field separately instead of clearing every name setting.
If you encounter a certificate error, check the system clock first, then confirm that the server name from the subscription is still present and that the server certificate is valid. Skipping certificate verification changes the connection's trust requirements and should not be your default troubleshooting step. If the service uses a private trust system, ask the service administrator for the correct trust configuration instead of permanently ignoring verification on every device. Application-layer protocol negotiation must also match on both ends. For related handshake errors, check the server's requirements rather than copying familiar-looking values from another configuration.
REALITY: Use the Parameters Provided by the Server
REALITY is a security-layer option in the Xray ecosystem. Common client fields include the server name, a public key provided by the server, a short ID, and a client fingerprint. The client uses public parameters; the server's private key must never be distributed to clients. The server name is not an arbitrary website name: it must be one permitted by the server configuration. Whether the short ID can be empty, and what value to enter, depend on the server's actual settings. If an import keeps only the protocol and UUID but drops these parameters, the entry may still appear in the list but will not connect properly.
The client fingerprint selects a particular handshake behavior; it does not represent a browser identity, account identity, or speed tier. Supported values and related features vary by core, so use the value specified by the configuration source and supported by your current core. Flow and REALITY are also separate settings: flow is protocol behavior, while REALITY is a security layer. They often appear together but must be checked independently. If the logs report an unsupported security type, check the core first. If the handshake starts but fails, check the server name, public key, short ID, and network reachability.
A reliable check order is: confirm the server address and port, check the proxy protocol and credentials, check the transport fields, then verify the security-layer parameters. Keep the specific error from the logs after checking each layer. This helps distinguish an unreachable endpoint, a transport mismatch, and an identity verification failure. If you change the path, server name, and flow all at once, you may restore the connection without knowing which setting fixed it. The same issue may return the next time the subscription updates.
4. Project V, V2Fly, and Xray Core Families
Project V is a useful starting point for understanding this ecosystem, with V2Ray as one of its widely used core projects. The V2Fly community continues related development and maintenance, while Xray evolved from a similar code and design background into an independently developed core. They share concepts but have added features and changed their implementations in different ways. They are not simply a new and old version of the same thing, so the name alone cannot tell you which one supports every configuration. Check support for the actual protocol, transport, security layer, and extension fields.
What the GUI Client and Core Each Do
v2rayN, v2rayNG, and v2flyNG are graphical clients for managing settings, importing subscriptions, organizing routes, and starting a core. The core does most of the work of handling proxy connections. A field appearing in the interface does not guarantee that the core currently in use accepts it; being able to import a link does not prove full compatibility at runtime. When troubleshooting a startup error, note the client name, the core actually in use, and the exact error text. “Imported successfully, but it doesn't work” is not enough to identify the cause.
On desktop, start with v2rayN and check which core is actually selected in its supported configurations and settings. On Android, v2rayNG is primarily based on the Xray core, while v2flyNG is an alternative for the v2fly core. Available features still depend on the core bundled with the app and the client implementation. Before switching clients, determine whether the problem is a missing protocol feature, a local permission issue, subscription conversion, or an incorrect server parameter. Changing the interface will not fix the same invalid credentials.
Shared Concepts Do Not Make Extension Fields Interchangeable
Both core families use concepts such as inbounds, outbounds, routing, and DNS, and some configuration structures are similar, which makes basic configurations easier to migrate. However, extended protocols, security layers, flow options, DNS behavior, and individual field names can differ. Check REALITY and common Vision flow combinations against Xray's documented support; do not assume they will work with a v2fly core. Conversely, a configuration generated specifically for one core cannot be made compatible with another simply by changing the file name.
When migrating settings, distinguish between share links and native configurations. A share link describes the connection parameters for one server; the client can then generate local access, routing, and DNS settings. A native JSON configuration may already include those settings and may depend on custom tags or file paths. The examples below illustrate common routing rule structures for the two core families. They must be merged into an existing configuration, with the referenced outbound tags defined. These are not complete, standalone configurations and do not change server authentication parameters.
{
"routing": {
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"port": "0-65535",
"outboundTag": "proxy"
}
]
}
}This rule sends private addresses through a direct connection, then routes other ports through a proxy outbound. If the rule matches against an address database, the runtime must have the required data files. If your configuration has no outbound named direct or proxy, replace the names with the actual tags; do not reference outbounds that do not exist. Rules are evaluated in order, so a broad match placed first can prevent later, more specific conditions from being reached. If a graphical client generates the configuration automatically, check whether that process will overwrite custom rules.
Keep a Rollback Option Before Switching Cores
Before changing core settings in v2rayN, back up the current configuration and record the existing system proxy, routing mode, and DNS settings. After switching, first confirm that the core starts, then test the same server configuration. If the logs clearly report an unknown field or unsupported security type, restore the previous settings and check the supported features. Do not keep deleting fields until the program starts. Loading a configuration is only the first step; authentication, DNS resolution, and app access still need to be tested separately.
Client and core updates do not necessarily happen together. An interface change may affect configuration management, while a core update may change protocol support or default behavior. When reading release notes, focus on features relevant to your configuration rather than chasing version numbers. This guide does not set a universal minimum version. When downloading, choose the right installer from the platform-specific download page, keep your original configuration before migrating, and verify compatibility by testing the features you actually use.
5. Subscription Formats and Share Link Compatibility
A subscription URL is an entry point for retrieving a set of configurations, not a proxy protocol. The server may return a list of share links, encoded text, or a structured configuration format. The client must first identify the returned format, then convert each entry into settings it can edit and run. So “subscription updated,” “server entries appeared,” and “a connection was established” are three separate stages. Check each one independently; receiving some content does not mean every field was parsed correctly.
Similar-Looking Links Can Encode Fields Differently
VMess share links commonly contain encoded structured data. VLESS and Trojan often use address-like syntax, with credentials in the username position and transport or security fields in query parameters. SS share links also encode the encryption method and password. These are common conventions, not a guarantee that every generator uses identical formatting. Chinese notes, spaces, and special characters may need proper encoding. Never remove special characters from authentication data just to “clean up” a link.
The same setting may also have a different name in another format. For example, one share-link format might use a short parameter for the server name, while a native configuration stores it in a separate security object. Importers handle the mapping, but may not support every new extension. After importing, open the editor and check the protocol, transport, server name, flow, and REALITY parameters instead of relying only on the entry's note. If multiple entries have the same name, make sure you are testing the one that was just updated, not an older record.
Subscription Updates May Not Keep Local Changes
Many clients separate subscription management from manually added servers. Updating a subscription may recreate its entries. Changes made directly to a subscribed entry, such as its path, flow, or note, may be overwritten on the next update. If you need a temporary comparison, copy it to a separate manual configuration and label its purpose. Once you identify the issue, correct it at the subscription source instead of maintaining multiple diverging copies indefinitely. Do not stop updates just to preserve a one-time change; the server address or credentials may change and leave the local entry out of date.
In v2rayN, check the address and group under “Subscription Group Settings,” then update the subscription. On Android, check the same details in the subscription management and update screens. Menu labels may vary slightly between interfaces, but the checks are the same: Was the group saved? Did the request succeed? Can the client recognize the returned format? Does the target entry belong to the current group? If the number of entries drops unexpectedly after an update, check the update log and format before clearing everything. Backing up first preserves a useful sample for comparison.
| What You See | Check First | Next Step |
|---|---|---|
| Update request failed | URL, access requirements, subscription validity | Review the request error and confirm the full URL |
| Request succeeded, but no entries appeared | Response format; check whether the content is a login page | Check which client formats the source supports |
| Entries appeared, but startup failed | Extension fields and core support | Compare the specific error with the security settings |
| Starts, but authentication fails | Credentials, protocol, server time | Compare with the original parameters from the source |
Conversion Cannot Add Missing Features
Format conversion can map a field to its equivalent in another format, but it cannot give a core an implementation of REALITY if it does not support REALITY, or derive the correct value for a missing password. If fields are missing after import, first check whether they were present in the source content, then check whether the importer recognizes them. Do not submit a full subscription URL to an unknown conversion service; it often contains access credentials that could give someone else access to the same configuration set. When asking for troubleshooting help, share only redacted fields and error text.
Sharing a subscription across devices can keep server parameters consistent, but system proxy settings, VPN permissions, app filters, and DNS settings usually need to be configured separately on each device. Backup files may also contain device-specific paths or local ports, so do not assume they will work immediately when restored on another platform. See the multi-device configuration sync guide for migration details. For the initial import workflow, follow the Quick Start Guide; this section covers differences in formats and fields.
6. Comparing Connection Speed and Resource Use
“Fast” can mean a quick response on first access, steady throughput during a transfer, or a fast recovery after an idle period. Each depends on different factors. A first request involves DNS resolution, connection setup, a security handshake, and proxy authentication. Sustained throughput depends more on bandwidth, congestion, packet loss, server load, and device performance. Recovery after idle time may also depend on connection timeouts and mobile device sleep. Treating one test result as a verdict on an entire protocol can lead to conflicting conclusions.
Control the Test Conditions Before Comparing Protocols
If the server offers multiple protocol endpoints, compare them on the same device, with the same access method and at roughly the same time. Use the same app and task, and keep routing and DNS settings unchanged. If each protocol connects to a server in a different region, the results mostly reflect the network route, not the protocol. Also distinguish a first connection from a reused connection: a browser may load a page faster the second time because of caching or connection reuse, not because the protocol changed.
Protocol overhead can be understood in terms of handshake count, encapsulation layers, authentication work, encryption, and connection management. A leaner protocol layer may reduce some work, but complex outer transports or a device without relevant hardware acceleration can make the real-world difference less obvious. TLS session resumption may also reduce the cost of later connections, depending on the implementation and connection conditions. Without controlled testing, do not claim that one protocol is always faster or one encryption method always uses fewer resources.
CPU and Memory Reflect the Entire Processing Path
CPU use involves more than encryption: it also includes data copying, DNS resolution, rule matching, logging, and local access. TUN and system proxy modes use different processing paths, so testing one protocol with each mode mixes in the effect of the access method. Memory use may come from rule databases, active connections, DNS caches, and the graphical interface. High total client memory in Task Manager does not necessarily mean the protocol itself is memory-intensive. Compare both idle usage and changes under the same workload.
Multiplexing carries multiple logical streams over an existing connection. It may reduce repeated connection setup, but it also changes how congestion and failures affect traffic. Packet loss on the shared connection can affect multiple logical requests at once. Some transports already manage streams, so adding another multiplexing layer may not help. Follow core guidance for combinations that depend on a particular flow. Do not enable every multiplexing option in the name of “optimization.” Keep defaults first, then test for short-connection-heavy workloads or specific apps.
Test UDP, DNS, and Connection Recovery Separately
A webpage loading does not prove that the UDP traffic an app needs is being forwarded correctly. Real-time audio or video, some interactive apps, and certain transport paths may use UDP. Support depends on the local access method, proxy protocol, core, and server together. When choosing a configuration, identify the traffic types the app actually needs instead of inferring end-to-end support from the protocol name. If only one type of app has problems, check whether its traffic enters the proxy, whether UDP is routed to the right outbound, and whether the server allows that forwarding.
DNS performance cannot be judged by a single lookup either. Cache hits, parallel queries, where resolution happens, and routing policies can all affect later connections. If the browser has its own DNS feature, the client's DNS settings may not control every query. First determine where the request is resolved, then check whether the resulting address matches the outbound route. If changing protocols coincides with clearing the cache, a short-lived improvement may simply reflect a change in DNS state. Record the conditions before and after to separate the cause from the symptom.
If all protocols are slow at the same time, check the local network and conditions shared by the server first. If only the first access is slow, focus on DNS and the handshake. If transfers keep stalling, look at packet loss, idle timeouts, and resource load. If only one app is affected, check local access and routing. For a step-by-step method, see how to troubleshoot a slow connection. Choose a protocol after locating the problem, not as a substitute for diagnosis.
7. Android Battery Use and Background Connections
Battery drain on Android cannot be attributed to VMess, VLESS, or a core name alone. Once connected through the system VPN, the client processes network requests from selected apps. CPU wakeups, active wireless connections, DNS queries, reconnects, and logging all use power. The same configuration may behave differently on Wi-Fi and mobile data, and a weak signal can increase power use substantially. Before comparing results, keep the network, screen state, and foreground app consistent so differences in overall device usage are not mistaken for protocol effects.
VpnService Permission and Background Restrictions
The first time v2rayNG or v2flyNG starts a local VPN service, Android asks for system permission. After granting it, check the app status and logs, then verify that the target app can connect. The system VPN icon does not prove remote connectivity. If another app is already using the same type of connection, the current service may not be able to start. First confirm which service Android actually has running instead of repeatedly changing protocols. Some device manufacturers also impose additional restrictions on background services.
If the connection drops when the screen locks and recovers when you reopen the client, check battery optimization, background activity permissions, and auto-start settings. Menu paths vary by manufacturer; look for battery or background options in the system's app settings, and change them only for clients that need it. Relaxing background restrictions may keep the connection available for longer, but can also increase background activity. It is not a universal battery-saving fix. After changing a setting, test again with the same screen-lock duration to confirm whether the system was pausing or stopping the process.
Prevent Unnecessary Reconnects Instead of Disabling Encryption
Repeated connection failures can trigger repeated DNS lookups, handshakes, and authentication attempts, and on mobile networks may repeatedly wake the wireless radio. If the logs show the same handshake error over and over, fix the server name, security parameters, or system time instead of letting retries continue indefinitely. When switching between Wi-Fi and mobile data, the existing connection may stop working and need to be re-established. That recovery behavior alone does not mean the protocol is unstable. Note whether the problem occurs only after switching networks to distinguish it from interruptions during a steady connection.
Disabling the security layer to save power changes the connection's protection and is not a sound routine optimization. Check for unnecessary background app requests, repeated connection tests, verbose logging left on, and overly frequent subscription updates first. Use an appropriate logging level for troubleshooting, then restore your normal settings once you have enough information. If the device gets hot despite little network traffic, check for retry loops or misbehaving apps instead of assuming that the selected protocol's encryption is too demanding.
How Per-App Proxying Affects Which Requests Enter the Client
Per-app proxying can route only selected apps through the proxy or exclude selected apps from it; the exact options depend on the client interface. These modes do opposite things, so do not check only which apps are selected. After configuring the filter, test the target app again. Some apps rely on separate components for sign-in, downloads, or system services, so selecting the main app alone may not cover the full workflow. If a per-app setting sends the sign-in screen and main interface along different paths, some features may work while others fail.
Per-app proxying is not the same as domain-based routing. The former determines which apps' traffic enters the local tunnel; the latter decides which outbound handles requests after they enter the client. If an app is excluded, changing domain rules in the client usually will not affect it. Conversely, traffic from an included app may still be routed directly by a rule. Check the app filter first, then routing. Changing both at once makes it difficult to tell which layer caused the difference.
| Symptom | Check First | How to Verify |
|---|---|---|
| Connection drops when the screen locks | Battery optimization and background restrictions | Repeat the test with the same screen-lock conditions |
| Fails after switching networks | Connection recovery, DNS, and network state | Test on a fixed network and after switching networks |
| Only some apps have problems | Per-app mode, app components, and routing | Check each app that should enter the tunnel |
| Device stays warm while idle | Retry loops, background requests, and logs | Compare idle logs with the system battery records |
Assess battery use over a period of normal use, not from the percentage immediately after connecting. When reviewing the system battery records, consider app activity time and what you were doing; do not treat short-term fluctuations as a fixed result. See v2rayNG permissions, battery use, and per-app settings for practical steps. When choosing a setup, prioritize compatibility and a stable connection before optional optimizations. On mobile devices, avoiding repeated failures usually matters more than debating protocol names.
8. Choose a Setup and Verify Compatibility
Make the final choice by answering four questions: Which client does the device use? What complete combinations does the server offer? What access method and traffic types do the apps need? Can problems be reproduced reliably? Resolve compatibility first, assess performance next, and adjust optional optimizations last. No protocol is the best choice in isolation from the server and core. A stable, maintainable setup with clearly documented settings is usually better for daily use than a newer-sounding combination from an unknown source.
Everyday Desktop Use: Start with v2rayN
On Windows, macOS, or Linux, start with the appropriate v2rayN download for your platform and device architecture. The Windows desktop and classic WPF editions mainly differ in interface technology and workflow; that alone says nothing about remote protocol performance. See the Windows installation and setup guide for installation steps. If macOS raises a system permission prompt, see installation and permission troubleshooting. Get the client running before importing a configuration.
For browsers and desktop apps that follow system proxy settings, use the system proxy for an initial, minimal test. Consider TUN or another method only when you have a specific access requirement. Do not add custom DNS, complex routing, and a core switch all during the first import. Choose a complete configuration, verify that the core starts and that apps can connect, then restore any rules you need one at a time. If a working setup breaks after adding rules, revert the rules first rather than changing the protocol too.
Android: Choose Based on Core Requirements and App Scope
If the server offers a VLESS and REALITY combination that depends on Xray features, first verify that v2rayNG supports the full set of parameters you need. If you already have a configuration intended for a v2fly core, consider v2flyNG and confirm that its supported transports and fields match. When moving between clients, test one configuration before replacing all your data. Recheck system VPN permission, background permissions, and per-app selections in the new client.
If only a few apps need the proxy, consider per-app mode to limit which traffic enters the tunnel. If apps call one another, identify their related components first so you do not split the sign-in flow. For real-time communication or other UDP traffic, verify the entire connection path rather than testing only a webpage. On devices that frequently switch networks, also test recovery after screen lock and network changes to confirm the setup works under everyday conditions, not just immediately after connecting.
Use Different Decision Paths for Subscriptions and Self-Managed Servers
With an existing subscription, the provider generally determines the protocol. Choose a compatible client, preserve all fields, select an appropriate server entry, and check local access. Do not expect the client to convert one server-side protocol into another. If you manage the server, start with client and app requirements, then choose a protocol, transport, and security layer supported by both ends, and plan how to maintain certificates or keys. Avoiding unnecessary encapsulation can make troubleshooting easier, but never at the cost of authentication.
If you need to share a configuration across platforms, use the intersection of the features that all target clients actually support, rather than relying on success on just one device. You can keep separate configurations for different purposes, but label their intended devices clearly. After changing server protocols or security settings, test each device individually, paying attention to old entries, subscription caches, and manual copies. For custom native configurations, also check local paths, rule assets, and outbound tags. These are not server parameters you can assume will copy across devices unchanged.
Finish with a Consistent Verification Checklist
- Confirm the client and device architecture are correct, the core starts, and the local listening port is available.
- Check the protocol, address, port, authentication fields, and every required transport and security parameter.
- Confirm that the system proxy or VPN connection is active, then test with the actual app instead of relying on a status icon.
- Check DNS resolution, routing results, and the required traffic types separately. Keep a reproducible description of any errors.
- Finally, test after screen lock, network changes, or extended use, and confirm that settings still behave as expected after a subscription update.
If the cause is still unclear, restore a known-working configuration, compare the differences, and troubleshoot one layer at a time using this guide. Whether the request failed at local access, remote connection setup, handshake authentication, or routing and DNS determines what to check next. When asking for help, include the operating system, client, core type, protocol combination, and redacted logs. Never share passwords, UUIDs, or subscription URLs. To repeat the setup from the beginning, return to the Quick Start Guide. To choose an installer for another platform, visit the client downloads page. Avoid introducing several unverified settings while troubleshooting.