V2Ray Protocols and Cores
Technical Reference

Protocol layers: make sense of client settings

The client, core and server each have a different role

Choosing a setup starts with understanding how its parts work together—not with deciding which name sounds newer. v2rayN is a graphical client for managing servers, subscriptions and operating modes. The core handles connections, protocols, routing and DNS rules. The server must provide a compatible access method. Seeing a protocol in the client only means there is an editor for it; it does not guarantee that the active core, server configuration and imported format all support it.

Think of a connection in layers: local entry point, proxy protocol, transport, security layer and remote exit. The local entry point determines how an app hands off traffic, such as through a local proxy port set as the system proxy or through a virtual network interface. The proxy protocol handles authentication and requests; the transport determines how data is carried over the underlying connection; the security layer provides transport protection. The remote exit then connects to the destination. A mismatch at any layer can leave a browser waiting, but the fix depends on where it occurs.

Check the protocol and transport separately

VMess, VLESS, Trojan and Shadowsocks are proxy protocols or proxy solutions. TCP, WebSocket and gRPC describe transport methods; the two groups should not be compared as alternatives in the same category. VLESS can be combined with different transports and security settings, but actual support depends on the core and server. If the server requires WebSocket, selecting VLESS while leaving the transport set to plain TCP will not produce an equivalent connection. The path, host name and security settings must also match.

TLS and REALITY are not server addresses or separate subscriptions; they belong to the connection's security settings. A standard TLS connection requires checking the certificate and name against the server's identity. REALITY has its own identity-verification parameters and handshake. Putting both in the same client dropdown is a UI choice, not a sign that their fields are interchangeable. In particular, do not copy TLS certificate settings into REALITY or enter a REALITY public key in the user ID field.

Use the layers to understand imports and test results

A successful subscription import usually means only that the text could be parsed into a client entry. It does not prove that the remote port is reachable or that the authentication settings are correct. Likewise, a reachable port does not mean the protocol handshake succeeded: the underlying connection may come up, then fail because the name, path, user ID or security settings do not match. Check the connection in order: import parsing, underlying connection, protocol authentication, then access to the destination. Do not treat one success message as proof that the entire path works.

Routing and DNS can also affect what you observe. An app may not be routed through the client, or a domain may be sent directly; in either case, the result does not reflect the selected server. First test with the same app, the same destination and an explicitly chosen traffic-handling mode, then add split-routing rules. Change one layer at a time so you can tell whether the result comes from the protocol, name resolution or local entry point. Refer to the glossary for concise definitions of common fields, and avoid treating similarly named settings as the same parameter.

Proxy protocols: origins and design trade-offs

VMess and VLESS: two different design approaches

VMess is a key protocol in the Project V ecosystem. Its design brings user authentication, request handling and data protection together within the protocol. It has long had broad client and subscription support, making it a fit for deployments with a complete, compatible setup already in place. For modern configurations, check which authentication and encryption methods the implementation supports rather than copying legacy fields from old tutorials. For older shared configurations, verify that the current core still accepts those fields; a client saving them does not guarantee the core will handle them as before.

VLESS takes a leaner approach, reducing the responsibilities of the proxy protocol itself and relying on a compatible security layer or other controlled environment for transport protection. Leaner does not mean automatically secure, nor does it guarantee better speed than VMess in every situation. Public-facing deployments need an explicit transport protection design. A typical VLESS configuration includes a user ID, transport, security layer and optional flow control. Changing any one of these can break compatibility with the server. Choose a combination the server actually provides instead of chasing a protocol name.

Both protocols may show a user ID in the client, but similar fields do not make them interchangeable. Changing a VMess entry to VLESS generally changes only how the client generates its local configuration; it does not change the server's authentication protocol. Migration requires the server to provide a matching endpoint and a new configuration to be distributed to clients. If an existing connection is stable and there is no specific feature need or compatibility issue, keeping both sides aligned is usually better than changing a single dropdown.

Trojan and Shadowsocks: security dependencies and cipher requirements

Trojan commonly relies on TLS for transport protection and uses a password for proxy authentication. It combines established TLS capabilities with a straightforward proxy request model, but entering a password alone is not enough. The address, port, server name, certificate trust and transport settings must all match. If certificate validation fails, check the name, system time and server certificate chain. Disabling verification may change the error, but it also removes an important identity check and should not be a routine connection method.

SS is a common abbreviation for Shadowsocks, which uses a pre-shared key and a specified encryption method to establish a proxy connection. Its settings may look sparse, but the cipher name is part of the compatibility requirements. Cipher families can differ in key format, authentication and implementation requirements, so check the method as well as the password. The client and core must also support the specific method used by the server. For an existing SS service, verifying its cipher and key format is more useful than assuming that general SS support guarantees a connection.

Choose a complete configuration, not an isolated name

A protocol's history helps explain its fields, but it cannot replace testing in the actual environment. For example, fewer protocol headers may reduce some processing overhead, but a request also involves DNS resolution, a handshake, the remote exit and the destination's response. Differences a user sees may mostly reflect deployment location and network quality. Testing downloads from different servers and attributing the results to VMess or VLESS does not isolate the protocol and cannot be generalized to other devices.

For client selection, a more reliable order is to check whether the server provides a complete configuration, whether the active core supports those settings, whether the subscription can represent them fully, and whether the target app needs specific traffic features. If any of the first three requirements is unmet, a theoretical performance advantage cannot be realized. Do not guess missing flow-control, security-layer or cipher settings; ask the configuration provider for the original parameters and check them in the client. Protocol choice is first a compatibility decision, then a performance optimization.

REALITY and XTLS Vision: the boundaries of security layers and flow control

REALITY is not a proxy protocol alongside VLESS

REALITY is a transport security mechanism in the Xray ecosystem and is often used with VLESS, so shared configurations are often referred to by a single name. Still, understand the layers separately: VLESS handles proxy requests and authentication, REALITY handles the relevant handshake and identity verification, and Vision is a separate flow-control option. They work together, but they are not three synonyms that must always be bundled. A REALITY option in the client does not mean it can be combined with any protocol and transport.

Common client settings include the server address, port, user ID, server name, fingerprint, public key and short ID. The address points to the connection endpoint; the server name is used in the handshake and may differ from the address text; the public key is used for the corresponding server identity check; the short ID must match a value accepted by the server. Do not infer values from field names or put an arbitrary resolvable domain in the server name field. Use parameters from one valid configuration instead of piecing them together from several tutorials.

What PublicKey, ShortId and Fingerprint each do

PublicKey is public verification material used by the client and corresponds to a private key on the server. It is not a user ID or a replaceable label. The client needs only the public parameters required for the connection; it does not need and should never receive the server's private key. ShortId helps the server identify a configuration; accepted values, length and format depend on the implementation. Some configurations allow an empty value, but that does not mean other servers do. If the field is missing after import, check the provider's original entry.

Fingerprint selects a client handshake fingerprint behavior; it does not represent the device's operating system, and unusual values are not inherently better. It must be supported by the current implementation and suit the deployment. If an option is unavailable, first check the active core and client support rather than typing a plausible-looking name yourself. The server name is also distinct from the WebSocket Host field. Even when a deployment uses the same value for both, they belong to different layers and should be checked separately during troubleshooting.

When REALITY is selected as the transport security layer, check PublicKey and ShortId against the server configuration. Do not work around a failed handshake by disabling identity verification, guessing a name or mixing in parameters from another server.

Vision optimizes a specific data path

XTLS Vision is typically shown in the client's flow-control field as xtls-rprx-vision. It optimizes processing for specific traffic and transport combinations, including opportunities to avoid some redundant processing. It is not a general download-boost switch or a way to simply turn off encryption. The results depend on traffic patterns, the core implementation, and the security and transport methods in use. Select this flow control only when the server configuration and current implementation support it; do not add it mechanically to every VLESS entry.

Common deployments pair a TCP-based transport with an appropriate security layer, but whether Vision can be used depends on actual core support and server requirements. WebSocket, gRPC and other transports handle data and connections differently. The fact that they can also carry VLESS does not mean the same flow control applies. If the client reports unsupported flow control or an invalid combination after import, check the original configuration rather than removing the reported field just to make it pass validation.

Check settings in order and set realistic expectations

When adding an entry manually, first confirm which core is running. Then select VLESS and the correct transport, configure the security layer and flow control, and fill in the server name, fingerprint, public key and short ID. After saving, reopen the entry to check that the client retained the fields. If a setting disappears, the editor may restrict that combination, the importer may not recognize it, or the version may lack support. Check the client logs; seeing a server entry in the list is not proof that it works.

Evaluate this combination by prioritizing a successful handshake, then reliable access, then resource use under sustained load. A brief speed test may mostly reflect server bandwidth and does not prove a flow-control benefit; an occasional delay on the first packet may come from DNS or a mobile network reconnecting. For more background, read REALITY and XTLS Vision explained. In practice, both sides must use matching settings; do not change explicit server parameters just to use a particular technology name.

V2Fly and Xray: project lineage and configuration compatibility

Shared origins do not mean identical capabilities

Project V provides an ecosystem for modular proxy capabilities. V2Fly continues to maintain V2Ray-related implementations, while Xray has developed independently from related code and configuration traditions. They share concepts and configuration conventions such as inbounds, outbounds, routing and DNS, so many fields look alike. But the projects evolve separately, and support for protocol extensions, transport details, defaults and configuration validation may differ. Their shared lineage does not guarantee that every configuration will remain compatible in both directions.

For most users, the clearest effect of core differences is whether a given set of parameters works. REALITY and XTLS Vision are important reasons to choose Xray; configurations written for a specific implementation should generally use that target core. V2Fly is suited to existing deployments within its support range. There is no universal winner based on the project name alone: the server's features and the client's ability to generate the complete configuration matter more than abstract claims about which core is more advanced.

How three clients map to their cores

For desktop, v2rayN is the recommended starting point across Windows, macOS and Linux, with a consistent way to manage server entries, subscription groups and routing. The cores you can select depend on the installation environment and current client support. On Android, v2rayNG, which uses Xray, is usually the first choice; consider v2flyNG when matching a V2Fly deployment. Choose a client by platform and server requirements first, then subscription format. Similar interfaces do not mean two mobile clients have identical capabilities.

A graphical client converts server entries into configurations a core can read. This conversion layer may add defaults, rearrange the structure or filter unsupported fields, so the server editor is not a word-for-word view of the core configuration. If a saved option still does not work, check the startup logs to see which core the client actually launched, whether it accepted the generated configuration, and whether the error occurred during startup or connection. Troubleshooting at the core level and at the subscription level are different tasks.

Check settings one by one during migration; do not just change the name

Configuration compatibility has three layers: syntax, fields and behavior. Syntax compatibility means the file can be parsed; field compatibility means the relevant modules recognize the options; behavioral compatibility means they work as intended. For example, routing settings with the same name may be affected by default DNS behavior, and an outbound tag must be referenced correctly by rules. A core that starts is a necessary condition, but it does not prove that every routing, DNS and transport combination has been tested.

Before migrating, save the configuration exported by the original client and any useful screenshots, with subscription URLs, passwords and user information obscured. Migrate one server first and disable extra complex rules; test using a clearly defined local proxy entry point. Then restore domain rules, DNS policies and TUN handling step by step. If you change the core, protocol, DNS and operating mode all at once, it will be hard to identify the cause of a problem—and a local routing issue may be mistaken for a core incompatibility.

Keep a rollback plan when updating the core, too. A newer implementation may add support or validate fields more strictly than before. If an old configuration now reports an error, check the specific field before assuming the server is down. On the other hand, an outdated core may not recognize new subscription settings. See the client download center for installers and platform architectures, and the client selection guide for an overview of the three clients. This page covers capability limits; an update does not guarantee better performance in every environment.

Speed and resource use: which comparisons matter

Separate time to first response, throughput and connection stability

Connection speed includes at least three different measures. First is the time from making a request to getting a response, which is affected by DNS, the underlying connection and handshake round trips. Second is sustained throughput, which depends more on link capacity, congestion, server load and exit limits. Third is whether a connection stays up and how quickly it recovers after an interruption. A setup may respond quickly but deliver average download speeds, or hold long connections reliably while taking slightly longer on the first request. One speed-test number cannot describe all of this.

Protocol overhead exists, but its impact must be considered across the entire path. The routes from the user to the server and from the server to the destination, as well as the destination service itself, can all be bottlenecks. Comparing different servers does not isolate protocol differences; comparing different times may introduce changes in load. To assess a transport combination, keep the device, entry location, target file, test tool and traffic-handling mode as consistent as possible. Alternate tests over multiple runs rather than treating a brief fluctuation as a stable result.

Handshake layers and connection reuse each have trade-offs

TCP, TLS and application-layer transports can have different connection setup sequences. WebSocket and gRPC also add their own protocol framing, deployment flexibility and connection management. Extra encapsulation typically means more processing, but whether it becomes a bottleneck depends on the server deployment, connection reuse and traffic patterns. Counting protocol names cannot tell you that a combination will be slower; sharing a port does not mean two combinations have the same handshake cost.

Connection reuse can reduce repeated setup in suitable cases, but it changes how multiple requests share an underlying connection. If the shared connection is congested or has a problem, several requests may be affected together. Some apps already maintain their own long-lived connections, so additional reuse may bring little benefit. Configure it according to the core, protocol and traffic requirements; it is not a universal speed boost to enable on every server. After a change, check both short-request responsiveness and sustained connection behavior.

CPU and memory depend on the workload

Encryption algorithms, hardware instruction support, protocol framing and data copying all affect CPU use. An older processor may hit its compute limit at high throughput, while a newer device may be limited mainly by the network. The same protocol can therefore perform differently on two devices without contradiction. When monitoring, track sustained use by the client and core processes and check whether a single core is close to saturation. Low overall system usage does not rule out a compute bottleneck, and a brief peak is not the same as a sustained load.

Memory use depends on concurrent connections, buffers, routing data, the DNS cache and logs. Monitor the graphical client separately from the core; TUN and other traffic-handling components may add their own workload. Comparing a complete desktop client with a standalone background core does not compare equivalent functionality. On a resource-constrained device, first reduce unnecessary concurrent speed tests and verbose logging, then observe baseline usage during normal activity. This helps distinguish test-generated load from everyday resource use.

Keep reproducible local test notes

At minimum, record the operating mode, core, full protocol combination, network type and test task. Repeat the test with the same server before changing one setting. If the change also requires a server-side adjustment, make sure both ends match. Do not mix automatic retries after connection failures, background subscription updates or continuous speed tests into normal browsing data. Results apply only to the conditions tested; they are not a universal ranking of protocols across regions, devices and apps.

For most users, reliable connections, maintainable settings and clear parameter sources matter more than theoretically removing a few processing steps. If a setup already meets your needs, there is no reason to keep changing transports. Adjust protocol settings only after confirming that the bottleneck is local processing, handshakes or connection management—not the network link or destination service. Optimizing after functionality is verified helps avoid new problems in pursuit of differences that cannot be reproduced.

Mobile battery use: ongoing costs beyond the protocol

Battery drain comes from the entire connection path

You cannot judge mobile battery use from the protocol name alone. CPU encryption, virtual network interfaces, packet forwarding, wireless activity and background app requests all consume resources. Even when the proxy carries little user traffic, frequent keepalives, reconnects and background speed tests can prevent the device from entering deeper sleep. To assess a configuration's battery impact, consider actual traffic volume, connection resets and background behavior with the screen off—not just one percentage in the client's battery display.

Wireless activity matters in particular. Mobile data and Wi-Fi use different connection-management and power-saving mechanisms; even small but frequent requests can keep the radio active. Some long-lived connections send periodic keepalives to stay active through the device, router or network intermediaries. A shorter keepalive interval may improve availability in a specific environment, but it also increases activity. A longer interval may make the connection more likely to expire, so choose based on the app's needs.

Full-device and per-app traffic handling

On Android, a client can use the system VPN interface to handle local traffic, including traffic from apps that ignore ordinary proxy settings. A wider scope means more background tasks may use the same data path. An app that normally communicates only on the local network may start retrying remote addresses if routed incorrectly; a sync app that keeps failing may repeatedly open new connections. These activities may be attributed to the client in usage statistics, even though encryption or the proxy protocol itself may not be the cause.

If the client supports per-app inclusion or exclusion, narrow the scope to what you actually need and keep track of which apps bypass the proxy. Split-routing rules must also align with DNS handling; otherwise, an app may connect directly while its name is resolved through a different path, causing delays or duplicate requests. For apps that rely on local-network discovery, printing or controlling home devices, verify their behavior individually instead of repeatedly trying broader rules. Eliminating unnecessary requests is often more effective than changing protocols.

Balance background limits with persistent connections

Battery optimization may restrict background processes. If the client stops, app requests may time out or trigger frequent reconnections. Relaxing background restrictions can be necessary for persistent connections, but it does not automatically reduce battery use. First determine whether the process was paused, reclaimed by the system or disconnected because the network changed. Disabling every power-saving restriction whenever a connection drops expands background activity without necessarily fixing a handshake or DNS problem.

v2rayNG is usually the preferred Android option for Xray configurations; v2flyNG is for deployments paired with V2Fly. Differences in UI and implementation may affect available features, but they do not support a fixed battery-life ranking. For a fair comparison, use the same device, network, similar signal strength, app task and traffic-handling scope. Keep screen brightness and other background apps as consistent as possible, since their battery use may outweigh any difference in the proxy path.

Before comparing protocols, rule out continuous speed tests, verbose logs, retries on dead connections and unnecessary app traffic handling. Background activity you can explain is more useful for diagnosis than a single battery percentage.

Use controlled comparisons to find the cause

First check standby behavior with the client closed, then with the client open but no active traffic, and finally while performing the same browsing or download task. For each run, note whether the network changed, the connection was recreated or errors continued. Battery statistics are often delayed and depend on how the system attributes usage, so very short test windows are unreliable. A hot device may also throttle its CPU, reducing speed and making the protocol look slower when heat and workload are the real causes.

If background logs show repeated timeouts, check the settings, DNS or routing first. If the connection fails only after a network change, check whether the client reconnects and resolves the address again. If only one app causes problems, investigate its traffic. To learn how TUN handles traffic, read How TUN mode works and how to enable it. Mobile permissions and background behavior still depend on the device OS and client. Choose a protocol for stable operation, not as a substitute for diagnosing system-level battery use.

Subscriptions and configuration: format compatibility does not guarantee complete settings

A subscription distributes configuration; it is not a connection protocol

A subscription URL retrieves server entries. Its contents may be a collection of share links, encoded text or a structured format defined by the client. Fetching a subscription and connecting to a proxy server are separate processes: a failed update does not necessarily mean existing servers are unusable, and a working server does not guarantee the subscription URL is still valid. When troubleshooting, distinguish a fetch failure, a parsing failure, a field-conversion failure and a connection failure instead of treating every issue as an unavailable subscription.

Share links put parameters in different places, such as the address, query fields or an encoded structure. User IDs, passwords, ciphers and transport settings do not map one-to-one across protocols. Even when two clients both support the same share-link format, they may handle extension fields, defaults and name encoding differently. Simple entries are more likely to transfer cleanly; with REALITY, flow control or newer transport options, check that the importer preserves all required fields.

Reopen imported entries and check the settings

At a minimum, check the address, port, protocol, authentication details, transport and security layer. For WebSocket, also check the path and related host settings; for gRPC, check the service name and deployment requirements; for REALITY, check the server name, fingerprint, public key, short ID and flow control. An alias is only a local label, and matching names do not mean the configurations are identical. After a subscription update, check that the selected entry is still present and that the client has not switched to a different entry with the same name.

A subscription provider may change parameters or replace servers, so manual edits to subscription entries may be overwritten by a later update. For temporary experiments, make a local copy and label its purpose so untraceable changes do not get mixed into the original group. Even if a test works, confirm that its settings match the server's requirements rather than merely bypassing one routing issue. Groups help track sources and update boundaries; they are not just a way to combine every link into one long list.

Understand the core configuration generated by the client

This minimal configuration is for understanding the relationship between inbounds and outbounds locally. It listens for SOCKS connections on a loopback address and forwards received requests directly to the system network. It uses common modules available in both core families, but the environment must support them and the port must be free. It does not include a remote proxy and should not replace a subscription configuration. If you manage connections through a graphical client, there is no need to run a core separately just to read this page.

{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "auth": "noauth", "udp": false }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

In this example, the inbound tag identifies the local entry point, the listen address limits where connections can come from, the port lets apps find the entry point, and the outbound determines how data leaves the core. A real client also generates proxy outbounds, routing and DNS settings. Do not change the listen address to all interfaces just to let other devices connect; that changes the exposure scope and requires separate consideration of authentication, firewalls and usage boundaries. The goal is to understand the data path, not to broaden access.

Share configurations safely and troubleshoot parsing

A subscription URL may grant access, and an exported configuration may contain passwords, user IDs or other connection credentials. When asking for help, share only the protocol, transport, core name and a redacted error summary. Do not publish the full subscription or paste a complete configuration into an unfamiliar online converter. Even if some fields are public verification material, other fields in the same entry may be sensitive; review them individually before sharing.

If an update fails, first check that the URL is still valid and the system time is correct, then look for connection or certificate errors and confirm the response is actually a subscription rather than an informational page. If the update succeeds but fields are missing, investigate format and importer compatibility instead. For more on configuration modules, see Understanding JSON configuration structure. For your first import, follow the configuration guide and verify the basic connection before adding complex custom settings.

Choosing a setup and troubleshooting: from complete configuration to reliable connection

Narrow down options by platform and server capabilities

For desktop, start with v2rayN and choose the installer and architecture for Windows, macOS or Linux. On Android, consider v2rayNG for Xray configurations and v2flyNG for deployments paired with V2Fly. Next, check which protocol, security layer and transport combination the server provides. Choosing a client is not about picking the theoretically strongest protocol from a blank list; choose from the intersection of platform availability, core support, complete subscription settings and server compatibility.

If an existing VMess or Trojan service is stable, keeping its correct configuration is usually better than switching to VLESS on your own. If the server explicitly provides VLESS with REALITY and Vision, choose a client and core that can handle the full set of parameters. If you only have an SS configuration, check the specific cipher and key requirements rather than selecting a similar-sounding type. A protocol migration requires a new server endpoint and complete settings; changing a type in the local UI cannot do it by itself.

Choose traffic handling based on what you need

For browsers and apps that follow system proxy settings, start by testing basic access through the system proxy. Consider TUN when you need to cover other apps. TUN changes which local traffic is handled; it does not fix remote authentication or security-layer errors. First verify that the server works through a standard local proxy entry point, then deal with permissions, the virtual interface, routing and DNS. If device-wide access fails after that, you can focus on local traffic handling instead of rechecking every remote parameter.

Development and local-network workflows also require checking how local services, internal domains and private addresses are routed. Rule order can determine which outbound is used, and DNS policy affects decisions based on domains or addresses. Do not stop after adding a broad rule; test public access, internal services and name resolution separately. For more on how the fields work together, read DNS split routing explained, and keep a clear record of each test after making changes.

Use the failure stage to guide troubleshooting instead of repeatedly reinstalling

If the core fails to start, first check configuration syntax, unknown fields, missing support or a local port conflict. Whether the remote server is online is not the priority yet. For an underlying connection timeout, check the address, port and current network; a refused connection usually calls for checking the destination listener and access conditions. Investigate user details, the security layer, server name and related settings only when the handshake fails. The failure stage narrows down the possibilities, but an individual log line needs context and does not point to one unique cause.

If only some sites or apps fail, first confirm that their traffic reaches the client and which rule sends it to which outbound. DNS errors, destination restrictions and an app's own proxy behavior can all cause isolated failures. Changing protocols may not fix the issue and can remove a useful baseline for comparison. Before temporarily disabling custom rules, save the original settings. Once the basic route works, restore rules one at a time to find the one affecting access.

Recommended order: configuration loads → remote connection established → handshake and authentication complete → destination accessible → routing behaves as expected → then optimize speed and battery use.

Keep the final configuration maintainable

After testing, record the client, active core, server source, protocol combination and necessary local rules—but do not record credentials intended to remain private. Keep a known-working baseline and change one variable at a time during future updates or tuning. When something breaks, compare against the baseline rather than combining a client reinstall, core change, protocol switch and routing reset in one step. A configuration that is reversible and easy to explain is easier to maintain than one packed with settings.

New users can follow the quick configuration guide to import and verify a connection, or consult 10 common V2Ray questions for beginners to troubleshoot common connection problems. For a different platform's installer, use the download center; client installers are not found in subscription entries. The selection principle throughout this guide is simple: keep the platform, core, protocol, transport, security layer and parameter sources aligned, then verify stability with real tasks instead of judging connection quality by names alone.