V2Ray Protocol and Core Guide

Configuration Layers: Understand Where Each Setting Belongs

The “server type” in a client does not describe the entire connection. A typical proxy connection involves an app entry point, proxy protocol, underlying transport, security settings, and routing destination. The address and port specify where to connect; the UUID or password identifies how to authenticate; TCP or WebSocket carries the data; TLS or REALITY belongs to a separate security negotiation. Understanding these settings separately is more useful than memorizing combinations, and helps prevent entering a server’s required security method in the protocol dropdown.

How Protocol, Transport, and Security Layers Differ

VMess, VLESS, Trojan, and Shadowsocks are the proxy protocols covered here. They define how the client and server represent destination addresses, authenticate, and handle proxy traffic, but differ in capabilities and security models. TCP, WebSocket, and gRPC are transport methods; TLS is a widely used transport security mechanism. REALITY is a secure transport option in the Xray ecosystem. It is commonly used with VLESS, but is not a peer protocol that can independently replace the server type.

When reading a VLESS configuration, check the server type first, then the transport, and finally the security layer. For example, if the server requires TCP with REALITY, the client cannot switch to WebSocket with standard TLS just because the UUID is the same. Likewise, two VMess entries may not be interchangeable if their paths, hostnames, or transports differ. Whether a connection works depends on the full set of matching parameters, not just the protocol name in the list.

Address, Name, and Path Are Different Settings

The server address establishes the underlying connection, the TLS server name is used for name verification and negotiation, and the WebSocket Host is part of the application-layer request. These values may sometimes match, but they are not inherently tied together. Enter different values only when the server explicitly provides them; don't copy values into every field based on guesswork. The port is simply the server's listening endpoint: a familiar port does not automatically mean TLS is enabled or that the transport is correct.

The WebSocket path must match the server and reverse proxy configuration. The leading slash, letter case, and query string can all affect matching. A gRPC service name is not the same as a regular web path. Blank fields after import are not necessarily missing: some protocols don't use them, and some clients apply defaults. Check the protocol and transport combination before deciding; don't fill in a path copied from an unrelated guide.

Troubleshoot Local Access and Remote Protocol Separately

Desktop apps connect to a local SOCKS or HTTP endpoint first. The core then routes traffic directly or through a proxy. The local port is not the remote server port; changing one does not change the other. The system proxy is not part of the protocol either: it only affects apps that use the system proxy settings. If an app bypasses the proxy, first check how it connects rather than immediately changing the remote protocol.

Android VPN mode uses a virtual network interface to receive in-scope traffic and pass it to the core. Its coverage differs from the desktop system proxy. A connection icon only confirms that local access is active; it does not prove that remote authentication, DNS, and routing are working. Read the logs in this order—whether a local request arrived, where routing sent it, and whether the remote connection succeeded—to separate the checks.

VMess and VLESS: Different Design Trade-offs

VMess and VLESS are both common in clients related to Project V, but they have different design goals. VMess comes from the earlier V2Ray protocol stack and incorporates identity authentication, request handling, and traffic protection into its design. VLESS is widely used in the Xray ecosystem; its lighter protocol structure relies more on external mechanisms for secure transport. Neither is universally better regardless of server setup. Start with what the server provides and whether the selected core supports the complete combination.

VMess: Modern Authentication and Legacy Configurations

A VMess UUID is an identity setting, not a server address or a label that can be freely replaced. Modern VMess configurations should use AEAD authentication. The extra ID, or alterId, seen in older materials is a legacy compatibility detail; don't enter an arbitrary non-zero value based on an outdated guide. Support for legacy modes varies between servers and cores, so check the provider's current requirements when importing an older subscription.

VMess authentication involves time, so a significantly incorrect device clock can cause authentication to fail. If the address is reachable but the handshake fails, check the system date, time zone, and automatic time setting, then verify the UUID and server status. But a VMess failure does not automatically mean a clock issue: a wrong transport path, TLS configuration, or remote port can also cause connection failures. The error stage in the logs is more useful for narrowing things down than a generic timeout.

VMess works with different transports, so you can't estimate its resource use from the protocol name alone. VMess over WebSocket and TLS may differ from a directly carried configuration in handshake, encapsulation, and connection reuse. If your existing VMess setup is stable, subscriptions update correctly, and it meets your needs, there's no reason to switch just because another protocol name is more common. Migrate for a specific reason, such as consistent core support or removing an unnecessary transport layer.

VLESS: A Lightweight Header Is Not a Complete Security Setup

VLESS mainly handles proxy requests and identity information; it does not provide the same payload encryption mechanism as VMess. The common encryption value `none` in a client is valid for this protocol field and does not mean the entire connection is necessarily sent in plaintext. To assess transport protection, check for outer TLS, REALITY, or other security measures in the deployment. Don't judge the overall security of a connection from the `none` field alone.

Likewise, a complex-looking UUID does not mean VLESS can do without outer protection. An identity token and confidential transport solve different problems. Import the full security combination provided by the server; don't disable the security layer to reduce the number of settings. If the provider supplies a record without explaining its security, clarify the deployment and its intended use before treating it as a general-purpose public configuration.

VLESS Flow, Transport, and Server Support

The VLESS `flow` field is not a general-purpose speed boost. Some Xray configurations use xtls-rprx-vision, which requires the server, client core, and transport to meet specific conditions. Copying this value into any VLESS entry may cause the configuration to be rejected or the handshake to fail. In particular, don't combine direct-transport settings with WebSocket or gRPC fields without server-side guidance; that can produce a configuration with valid-looking names but an invalid combination.

An option appearing in the client editor doesn't guarantee that the selected core implements it. When checking VLESS, verify the UUID, transport, security type, server name, and flow in that order. Then check the REALITY public key and short ID separately. If the parameters match but the connection still fails, note the specific error in the core logs and continue troubleshooting authentication, handshakes, and DNS in the Help Center.

Keep the choice straightforward: continue using an existing, maintained VMess service with its original settings. If the server provides VLESS with explicit TLS or REALITY settings, choose an Xray client that supports that combination. Migrating protocols is not a matter of changing one dropdown. Authentication and security settings differ, so migration requires a complete new configuration from the server; keep the old one for comparison and testing.

Trojan, SS, and REALITY

Trojan, Shadowsocks, and REALITY often appear together in subscription lists, but they are not three equivalent alternatives. The first two are proxy protocols; REALITY is a secure transport option. Compare complete combinations, such as Trojan with TLS, VLESS with REALITY, or Shadowsocks with a specific encryption method. Saying a configuration “uses REALITY” is not enough to determine which client or settings it needs.

Trojan: Treat TLS as a Prerequisite

Trojan is designed to use a secure TLS connection, with clients typically authenticating proxy requests using a password. Check both the password and the server name and certificate verification requirements. The server address may be a domain or an IP address, but the TLS name must match the server's certificate and configuration. The address can be reachable while a name mismatch still prevents the proxy request from being established; changing the password won't fix that.

Don't routinely skip certificate verification to fix certificate errors. Disabling verification changes the connection's security boundary and can conceal an incorrect name, a device clock issue, or an invalid server certificate. Check the name, time, and certificate validity first, then confirm the settings with the provider. If a dedicated test environment uses a self-signed certificate, configure trust for that environment rather than carrying the test workaround over to everyday connections.

Shadowsocks: The Method Is Part of the Protocol

Shadowsocks, often shortened to SS, is a distinct protocol built around lightweight proxying and encrypted transport. Clients generally need an address, port, password, and encryption method. The method is not a local preference you can choose freely; it must match the server. Legacy stream ciphers, common AEAD methods, and newer protocol variants have different compatibility ranges. Similar-looking options in a client dropdown don't mean they can interoperate.

The required password format can also vary by method. Some methods accept a plain-text password, while some newer ones require an encoded key of a specific length. Entering a text password directly may cause an error during local parsing. If an imported subscription shows only an address and password but omits the method, plugin, or other parameters, treat it as an incomplete record. Whether a plugin is needed depends on the server and core support; don't remove one and assume nothing will change.

SS can offer simple configuration with fewer encapsulation layers, but that doesn't guarantee lower battery use or higher throughput on every device. Results still depend on the encryption implementation, processor, transport quality, and app request patterns. If your use case needs UDP, confirm that both the server and local entry support UDP forwarding. A successful web page load doesn't verify this or prove that every app will work.

REALITY: Check the Public Key, Short ID, and Server Name

REALITY uses an authentication setup that differs from standard certificate deployments. Common client fields include the server name, public key, short ID, and client fingerprint. The public key must match the server configuration; don't copy it from a standard certificate. Preserve the short ID exactly, and don't remove it just because it looks like a label. Whether it can be empty depends on the server; don't fill it in using a value from another configuration.

The client fingerprint relates to handshake characteristics; it is not an account password. Use a value supported by the current core and required by the deployment. Changing it at random does not improve performance. The server name must also be one allowed by the server, not an arbitrary website domain. If a connection fails, check the name, public key, short ID, fingerprint, time, and flow in that order; this is more useful than repeatedly changing the port.

Choose based on what the server supports. If you need standard certificate verification, consider a well-maintained Trojan configuration. For an existing SS service, first confirm method compatibility. For REALITY, choose an Xray core that explicitly supports the combination. You can't migrate between these by changing only the protocol name; the complete parameters in the subscription are what the client needs to connect.

Connection Speed and Resource Use

“Fast connection” can mean at least three different things: time to establish the first request, sustained download throughput, and time for many small page requests to finish. A shorter protocol header may reduce a little processing, but it doesn't mean fewer network round trips. Higher sustained throughput also doesn't necessarily make the first page load faster. Before choosing a setup, identify the main workload—short requests, long-lived connections, video streaming, or waking after frequent idle periods—instead of using one test to represent every scenario.

Break Down the Handshake

A cold-start request may involve DNS resolution, an underlying connection, security negotiation, proxy authentication, and a connection to the destination. Some transports add another application-layer setup step. Time spent in each stage affects the first response, so server distance, DNS status, and packet loss often matter more than fixed differences in protocol headers. If DNS keeps timing out, switching authentication protocols won't eliminate the delay.

Transports such as WebSocket and gRPC suit specific deployment setups, but add their own encapsulation and connection management. A directly carried connection is usually simpler in structure, but must match the server's entry requirements. Don't remove transport settings just to have “one less layer”; doing so can prevent requests from reaching the right service rather than create an equivalent, faster connection. Compare combinations the server actually supports.

How CPU, Memory, and Throughput Interact

Encryption, user-space traffic forwarding, buffer copying, and rule matching all use resources. Results vary with hardware acceleration, core efficiency, and the number of simultaneous app connections. A low-end device may hit CPU limits first, while a desktop may be limited mainly by remote bandwidth. Ranking resource use by protocol name alone hides the real bottleneck and makes it harder to identify settings worth changing.

Memory use does not equal protocol overhead either. Rule databases, DNS caches, connection counts, the client interface, and log buffers can all use memory. Higher usage after a client has been running for a while doesn't by itself mean the protocol is leaking memory. When monitoring, distinguish the client process from the core, keep the workload consistent, and check whether usage keeps growing without falling before deciding to report a problem.

Validate Connection Reuse and Keepalives Against Your Workload

Connection reuse can reduce the cost of repeatedly establishing connections, but it can also make multiple requests share some transport state. Packet loss, server implementation, and connection closing policies can all affect results. Enabling another reuse option on a setup that already uses mature multiplexing may not help. If some sites hang while large downloads work but small requests fail, disable additional reuse in a copy of the configuration and see whether the problem goes away.

Keepalives also involve trade-offs. More frequent keepalives may reduce reconnects after idle periods, but can wake a mobile radio more often. Less frequent keepalives may reduce background activity, but the first request will need to establish a connection again. Don't apply the same “performance tuning” to an always-powered desktop and an Android device on standby. Defaults are usually the best starting point; adjust them only when you observe a specific problem.

A Repeatable Comparison Method

Turn off background downloads and keep routing the same; confirm both configurations use the same destination. Then run a cold-start visit and a sustained transfer for each, repeating several times instead of judging one result. Record failure rate, first response time, transfer stability, and noticeable device heat. A client's latency test may cover only one test address or part of the handshake, so it doesn't automatically represent a full web session or UDP performance.

If the two configurations use different servers, you can only conclude that they perform differently under the current conditions—not that one protocol is always faster. To isolate the effect of the protocol, keep server location, bandwidth, and load as similar as possible. If you can't control those conditions, prioritize compatibility, maintenance, and sustained availability over repeated switching based on a small difference in a single test.

V2Fly and Xray Core Families

Project V provides useful background for understanding this ecosystem. V2Ray introduced a composable architecture for inbound and outbound connections, routing, and transport. V2Fly continues development of V2Ray-related cores, while Xray evolved from this technical foundation and added its own protocol and transport capabilities. They share some terminology and configuration concepts, but their core files are not interchangeable without qualification. Check specific feature support rather than assuming compatibility based on their shared origins.

The Graphical Client Is Not the Proxy Core

v2rayN handles desktop server management, subscription updates, settings, and core controls; the selected core processes the traffic. v2rayNG is a common Android client for Xray, while v2flyNG offers an option based on the V2Fly core. A button in the client interface doesn't prove that the core supports a given protocol. Similar-looking entries may also produce different configurations under different cores.

For desktop, use v2rayN to manage subscription groups, logs, and system proxy settings from one interface. Before changing its core type, confirm which implementation the target protocol needs. On Android, choose a client based on the core family the app's configuration requires. Don't assume the desktop core-switching steps apply to Android menus; available options depend on the installed version.

Shared Fields Do Not Guarantee Full Configuration Compatibility

Both core families may recognize basic concepts such as addresses, ports, users, and routing rules, but transport names, protocol extensions, configuration structures, and defaults may differ. Check support for features such as REALITY and Vision against the Xray core's capabilities. The fact that V2Fly can read a VLESS entry doesn't mean it can handle every Xray VLESS combination. The same checks apply when migrating in the other direction.

After a client parses a subscription, it usually generates a configuration for the selected core. Pasting an entire JSON file manually skips some of that conversion and can introduce fields specific to another core. If startup fails, check the logs for unknown fields, unsupported protocols, or invalid parameters, then verify where the configuration came from. Don't delete every field mentioned in an error just to make the program start; a removed field may be required for authentication or security.

Routing Rules: Check Semantics and Resources Together

Routing depends on outbound tags and rule databases. Even if the rule syntax parses, a missing outbound tag or a geosite category not included in local data can prevent startup or produce unexpected routing. The example below shows part of an Xray routing object, demonstrating how to route private addresses directly. It is not a standalone configuration: before merging it, confirm that a direct outbound named direct exists and that the required rule data is available.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

This rule only handles requests that can already match an IP condition. AsIs does not resolve every domain just to apply IP rules, so it cannot replace a complete setup for local domains and DNS. Add rules according to how local services are accessed. For information on rule data sources, updates, and references, see the geoip.dat and geosite.dat rule data guide to avoid mistaking missing data for protocol incompatibility.

Upgrade and Core-Switching Rollback

A core upgrade may fix issues and add features, but it can also enforce stricter validation for older configurations. Before upgrading, save the client configuration and important custom settings. Afterward, test a known-good entry first, then check subscriptions, routing, and special transports. Stop the current connection before switching cores to avoid mixing old process state with the new configuration. Logs are a more reliable way to confirm that the new core actually started than the name shown in the interface.

Open-source licenses should not be described as if they were all the same. The V2Fly core project generally uses the MIT License, while the Xray core project uses MPL 2.0. Clients, dependencies, and bundled data may each have different licenses; check the notices for the specific release. For everyday users, open source means the implementation and license can be reviewed—it does not replace checking settings, verifying certificates, or independently evaluating a service provider.

Subscription Formats and Parameter Compatibility

A subscription is a way to distribute configurations, not a proxy protocol. A subscription URL may return a list of share links, Base64-encoded text, or structured configuration for a particular client. The client must understand the outer format, convert each entry to its own server model, and then generate a core configuration. So “the subscription URL opens,” “the entries import,” and “the server connects” are separate stages; success at one does not confirm the next.

How Much Information Share Links Can Carry

Common share links use protocol prefixes to identify the type, but field encoding varies between protocols and older implementations. VMess links often contain encoded structured data; VLESS and Trojan links commonly use an address with query parameters for transport and security settings; SS links also come in different encoding forms. Remarks are usually just display labels and don't affect authentication. Query parameters for paths, names, and security settings may directly determine whether a connection works.

An importer may recognize a protocol prefix but not support an extension field in the link. The client showing a server entry doesn't mean it preserved flow, public keys, short IDs, service names, or plugin parameters. After importing, open the editor and check protocol, security, and transport fields one group at a time. For complex entries, look for fields that were cleared, reset to old defaults, or silently ignored as unknown.

Base64 Is Encoding, Not Access Protection

Encoding a list of links as Base64 can make it easier to distribute as text, but it does not keep account details confidential. A subscription URL may itself contain an access token, so sharing it can grant others permission to update the subscription. Don't post a full subscription URL, QR code, or server details in public logs. For help, sharing the protocol type, failure stage, and redacted field names is enough to assess most compatibility issues.

If a subscription update leaves the list empty, the response may have been a login page, an error message, or an unsupported format—not a subscription with all servers deleted. Check the URL and format first, then see whether the update requires an existing proxy. If that proxy is down and the update depends on it, you can end up in a loop. Follow the subscription update failure and empty import checklist for a more complete process; don't keep deleting groups and importing them again.

Moving Between Clients

When moving to v2rayN, v2rayNG, or v2flyNG, use the original subscription supported by the target client rather than passing it through several conversion tools first. Each conversion can lose fields the target format cannot represent. If the provider offers multiple output formats, choose one explicitly intended for your client and core. A downloadable configuration in another format does not necessarily mean these clients can read it directly.

A single share link exported locally works for moving a small number of entries, but usually doesn't include routing, DNS, app scope, or interface preferences. After importing the server, check these local settings again on the new device. Android app routing scopes do not automatically become desktop system proxy settings, and desktop custom routes may not be included in a single server link. Backing up account configurations separately from device policies makes it easier to spot what's missing.

Subscription Updates and Manual Changes

Entries in a subscription group may be regenerated during updates, so manual changes to a subscribed server's port, name, or security settings may not last. To test an adjustment, first make a standalone copy and clearly label its source and purpose. That prevents future updates from silently overwriting your test conditions or making it look as though the provider changed the settings. Delete the copy to revert; there's no need to rebuild the entire group.

When managing multiple subscription groups, organizing them by purpose and source is more useful than sorting only by protocol. A subscription can include several protocols, and their settings may change over time. After each update, check that your usual entries are still there and that the selected entry hasn't changed, then make a real connection. If something goes wrong, keeping a working copy from before the update helps distinguish server changes from parsing or local core issues.

Android Battery Use and Background Activity

You can't judge battery use on mobile by protocol name alone. Running a proxy on Android uses power for wireless traffic, CPU processing, the system's virtual network interface, background app requests, and connection keepalives. Frequent small requests that repeatedly wake the cellular radio may affect standby more than one continuous download. Retries and network searches in weak-signal areas can also hide differences between protocols. First distinguish heavy use while actively connected from ongoing activity with the screen off.

Choosing Between v2rayNG and v2flyNG

For combinations that require Xray-specific features, consider v2rayNG on Android. If the server setup explicitly relies on V2Fly capabilities or needs that core, consider v2flyNG. Don't run both clients as active VPNs at once; Android restricts VPN service usage. For a comparison, stop one before starting the other and keep the app scope and routing the same. Otherwise, you're comparing different workloads, not core differences.

When you start the VPN service for the first time, Android's permission prompt confirms local traffic access; it does not mean the server has connected. After setup, visit an actual destination and check the logs for a valid request and the expected route. If only some apps fail, check the app scope and bypass settings first. An app excluded from the VPN no longer tests whether the proxy server works, so be clear about which route you're using during a test.

Balancing Background Restrictions and Connection Stability

System battery policies may restrict background services, network activity, or auto-start. If the connection drops with the screen off and immediately comes back when you reopen the client, check whether the system is restricting its background activity and adjust as needed. Menu names vary by device; use the system's battery management page. Allowing background activity can help maintain a connection, but you don't need to exempt every related app. Keep changes limited and reversible.

If the connection stays up but the device keeps heating up, first check for background sync, failed retries, or unusual DNS requests. Repeated failures can cause connections to be rebuilt, making the proxy process look like the source of battery drain when an app may simply be retrying nonstop. Temporarily narrowing the app scope or using a known-good routing preset can help isolate the cause. Increase log verbosity only while troubleshooting; continuous verbose logging also uses processing and storage.

DNS, UDP, and App Scope

DNS settings affect the wait before a connection and the number of requests. An unreachable resolver, DNS traffic routed through the wrong outbound, or mismatched local and remote results can all trigger retries. Don't add multiple DNS servers for “speed” without understanding the query strategy. Start with one clear resolution path, check that regular domains, local services, and proxy destinations are handled as expected, then expand one setting at a time.

Real-time communications and some interactive services may rely on UDP. If the protocol, server, or access route doesn't fully support it, an app may fall back to another method or keep retrying, affecting both performance and battery life. Working web browsing does not prove UDP works. Test with the actual service you need; check for frequent interruptions, long setup times, and abnormal reconnects, then consult the core logs. Don't blame every issue on Android background restrictions.

Include Real Standby in Battery Comparisons

Compare under similar signal conditions and for similar periods, with screen brightness, app scope, and background sync held constant. Observe active use in one test and screen-off standby in another, and record app activity in system battery statistics. Battery percentages are estimates, so small short-term changes aren't conclusive. Repeated wakeups, ongoing heat, or connection rebuilds during standby are more meaningful than a one-time difference of a single percentage point.

If local network devices are unreachable, first check routing for private addresses and local domains rather than forcing all traffic through the proxy. For rules that combine regions and use cases, see the v2rayNG split routing guide. Rules that reflect real usage are more likely to reduce unnecessary routing through remote servers. Stable, understandable settings are easier to maintain than a pile of supposed battery-saving tweaks.

Choosing a Setup and Verifying the Connection

Narrow down your options in order: confirm the device platform, check the complete protocol combination provided by the server, choose a compatible core, then set routing and access scope based on your workload. A protocol is not a standalone performance option; it is a communication requirement shared by the client and server. If the subscription offers only one maintained configuration, verify that one completely first. Request other combinations only if you have a clear reason, rather than adding maintenance work just to use a newer name.

Desktop Use, Android Mobile, and Existing Services

For Windows, macOS, and Linux desktops, start with v2rayN and choose the download page package that matches your processor architecture and system format. When using the proxy for everyday browsing and development apps, begin with clear system proxy and local entry settings, then confirm which apps use them. If an app requires explicit SOCKS settings, configure the entry in that app; “global routing mode” does not automatically take over every app's network traffic.

On Android, let the server's requirements determine whether to use v2rayNG or v2flyNG, then choose whether to include all apps or only selected ones. Switching between mobile data and Wi-Fi may require the underlying connection to be rebuilt; a momentary interruption on an old connection doesn't mean the protocol is unstable. If reconnecting keeps failing, check for DNS changes, remote reachability, and background restrictions. If you regularly use local devices, test LAN addresses and related domains separately.

For an existing, stable VMess, Trojan, or SS service, keep its parameters accurate and subscriptions up to date. If the server provides VLESS with REALITY, choose an Xray setup that explicitly supports its security fields and flow. To reduce device load, first look for unnecessary forwarding layers, repeated failures, and excessive background activity rather than simply switching protocols. On low-powered devices, a simple supported combination is usually easier to validate than a stack of complex settings.

A Repeatable Connection Acceptance Checklist

First, check that the local configuration starts. If the core exits immediately, address invalid fields, a port conflict, or missing rule data; traffic hasn't reached the remote server yet. Next, check DNS resolution and remote reachability. Then inspect security negotiation and protocol authentication. Only after these steps succeed should you troubleshoot the destination, DNS behavior, and routing. Working through stages prevents a local syntax error from being mistaken for an unreliable server.

Next, test the services you actually use: open a regular web page, access a work service, check a local network address, and test UDP apps if needed. Finally, check recovery from idle and network switching. Record the client, core family, protocol combination, and result for each step; there's no need to expose account details. If a step fails, keep a short log from that point. It's more useful when asking for help than logs mixed together after repeatedly switching servers.

Rule order and test destination

Routing rules are usually matched in order; a broad rule earlier in the list can override a more specific condition later. If some sites behave differently after changing protocols, check the generated routes and default outbound first instead of comparing only the server type in the editor. For custom domain and address conditions, see Xray custom routing rules and match order. Build rules around specific use cases rather than importing a large set of unexplained exceptions.

After testing succeeds, keep a known-good configuration as a baseline. For future subscription, core, or system updates, use it for a basic check before restoring complex routing and special options. The baseline isn't meant to stay unchanged forever; it gives you a point of comparison for every change. Once you've chosen a setup, return to the Getting Started guide for everyday use. Keep this manual for checking protocol boundaries, compatibility fields, and failure stages; there's no need to redo every setting before each connection.