The Complete V2Ray Guidev2rayN Setup & Maintenance

Core Concepts: Clients, Cores, and Connection Flow

How the GUI and proxy core work together

V2Ray usually refers to the proxy technologies and tools associated with Project V, not a single desktop application. v2rayN is a graphical client that stores server details, manages subscriptions, generates runtime configuration, and launches a core. The core listens on local ports, handles protocols, applies routing rules, and establishes outbound connections. A working interface does not mean the core is running, and a populated server list does not mean a usable server is selected.

V2Fly continues development related to V2Ray, while Xray is another core development path in the same ecosystem. Their protocol support and configuration details differ, so similar names do not mean all settings are interchangeable. v2rayNG primarily uses the Xray core; v2flyNG uses the V2Fly core. If a node will not import, first check whether the client and core support its protocol and transport combination instead of repeatedly changing the server address.

The actual path from app to server

With a standard system proxy, an app reads the system proxy settings and sends its request to a local listening port. The core receives the request, applies routing rules, and decides whether to connect directly or through a remote server. The remote server then reaches the destination and returns the data. At least four layers are involved: the app, the local listener, rule matching, and the remote connection. Check each layer in turn to tell whether the app skipped the proxy, the core failed to start, a rule chose the wrong route, or the server is unreachable.

A node is a set of connection parameters, commonly including a server address, port, user ID, protocol, transport, and security settings. A subscription is an address used to retrieve these parameters in bulk; it may also include groups or service information. A subscription URL is not a local proxy address and should not go in a browser's proxy port field. The client provides the connection software, but an authorized, active server configuration is still required to connect.

Protocols, transports, and security layers

VMess, VLESS, and Trojan are proxy protocols; WebSocket and gRPC are transport methods; TLS and REALITY relate to connection security. A node can include all of these layers, and an error in any one of them can prevent a connection. The server address may differ from the server name used for TLS, while paths and service names often need to match exactly. Import the fields provided by your configuration provider; do not combine parameters from unrelated examples.

DNS resolves domain names to addresses. Resolution may happen on the system, in an app or client, or on the remote side. Where it happens can affect the connection, especially rules that match by IP address. A successful DNS lookup only means an address was returned; a reachable port only means the transport reached a certain stage. Whether a browser can retrieve content also depends on handshake parameters, certificates, the destination service, and app settings. No single test can stand in for a complete connection.

Before configuring anything, map your connection path: which app makes the request, which entry it uses, which rule matches, and which server is selected. Those four details are enough to start; you do not need to study every core option. Each chapter adds one layer to this path. When you encounter an unfamiliar term, work out whether it relates to the entry, a rule, or an outbound connection before changing settings. This helps avoid confusion from changing several things at once.

Choose a Client: Platform, Architecture, and UI Version

For desktop, start with v2rayN

For desktop devices, start with v2rayN, then choose an installer based on your operating system, processor architecture, and distribution format. The cross-platform desktop UI supports Windows, macOS, and Linux; the WPF UI is for Windows. Both manage servers, subscriptions, and routing, but menus, layouts, and runtime requirements may differ. Do not switch your entire setup just to match an old screenshot. Look for the feature name and what the setting does.

Windows users choosing between the desktop and classic WPF versions can start with the workflow they already know. If you want a similar experience across devices, try the desktop version first. If you have a stable WPF working directory and configuration, back them up before considering a migration. Do not share a writable configuration directory between the two versions or let both control the system proxy at once. For UI differences, see Desktop vs. WPF: What's Different?.

Processor architecture and installation format

Architecture describes the processor a program is built for; it is not a network mode. On macOS, check your chip in About This Mac and choose the matching installer. On Linux, use the command below to check your machine architecture: x86_64 commonly corresponds to x64, and aarch64 to arm64. The package format must also match your distribution; do not assume a package made for one distribution will work with another. Check these basics before investigating runtime logs.

uname -m
cat /etc/os-release

On Android, v2rayNG is usually the first choice. Many recent devices use arm64, but check which app architectures your device actually supports. If you are unsure or see an architecture mismatch, look for a universal build. v2flyNG may be a better fit if you need the V2Fly core or want to check compatibility. Switching clients should not be your first troubleshooting step: confirm the subscription is valid, the protocol is supported, and the device time and network are correct.

Keep configurations separate when migrating

Configuration backups from different clients are not guaranteed to import directly into one another. Standard node share links are usually easier to migrate than copying an entire directory, but compatibility still depends on the protocol fields both clients support. Subscription groups, routing rules, shortcuts, and UI preferences may be client-specific, so record them separately. When switching, keep the old client, disable its proxy control, and test one node in the new client. Migrate complex rules only after the basic connection works.

Find all installers on the client download page. Choose in this order: operating system, architecture, UI version, then personal preference. If your device is managed by an organization, you lack administrator access, or you cannot install a virtual network adapter, consider whether an app-level proxy is enough. A working standard proxy does not guarantee that you have permission to use TUN. Treat permissions as a deployment constraint rather than repeatedly trying different installers.

Installation & Setup: Working Directory and First Run

Choose an installation location you can maintain

Start by choosing the right installer on the download page. Follow the installer prompts to choose a location. For an archive, extract all files before launching the program. Do not run it from the archive preview: temporary extraction may omit the core or resources, or lack write permissions. Choose a working directory that is easy to identify and back up, and avoid mixing files from different builds. With a portable setup, confirm where configuration is actually saved rather than assuming it sits beside the executable.

On the first run of v2rayN on Windows, install the runtime for the matching architecture if prompted, then restart the client. Do not try to fix dependencies by copying random system library files. If the program exits immediately, check its logs or Windows event information to distinguish a missing dependency from insufficient permissions or security software interference. For installation steps and first-run diagnostics, see Windows Installation and First-Run Troubleshooting.

Check the core and listener status

After opening the client, check the log for startup errors, missing files, or port binding failures. You can verify that the core is actually listening only after a node is available and the service is enabled. A typical local entry uses a loopback address and a listening port; check the current parameter settings for the actual port. Ports shown in older guides are examples, not values to copy over your current setup. Some builds may use a single combined entry rather than separate ports for two protocols.

Check the local listener options around Settings → Parameter Settings → Core Basic Settings. SOCKS and HTTP listeners serve different kinds of apps, so match the proxy type, address, and port in each app. For initial setup, listen on loopback. Use a LAN listener only when other devices genuinely need access. Exposing it to your LAN expands who can connect, so also plan access controls, firewall rules, and which devices you trust.

netstat -ano | findstr :10808

The command above shows how to check port usage on Windows. Replace the port number with the value in your parameter settings. The last column can help identify the process; confirm what it is before deciding to stop it or change the port. Do not terminate an unfamiliar system process just because it is using the port. If another proxy instance is listening, close the duplicate. If a legitimate app needs the port, change the listener port and update any apps with manually configured proxy settings. See How to Fix a Local Port Conflict for details.

Other desktop and mobile devices

After installing on macOS, follow the system prompts to allow the app to open. Check the source and app identity first; do not disable system-wide protections to authorize one app. On Linux, install with the package manager for your distribution and read any missing-component prompts. Desktop environment, graphics backend, and tray support can affect the UI. Closing a window may leave the process running, so check the tray and process list to see whether it is still active.

On Android, the first connection usually triggers a system VPN permission prompt. This permission is required to create the traffic entry. Import a valid configuration first, then confirm the prompt is for the app you are using. For the initial test, disable other tools that control network traffic so the two entries do not conflict. Success means more than opening the app: you should be able to find the configuration, read the startup log, and tell whether the service is running. Then you are ready to import a subscription.

Manage Subscriptions: Import, Update, and Organize

Create a group before updating servers

Subscription URLs often contain personal access tokens and should be treated like credentials. Get them only from an authorized configuration provider. Do not post the full URL in public comments, screenshots, or online conversion tools. A URL opening in a browser does not prove its response is suitable for your client; it might return an account page, an error, or another format. Before importing, make sure the address is complete and contains no extra instructions, line breaks, or punctuation added by a chat app.

In v2rayN, go to Subscription Group → Subscription Group Settings, add a group, enter a recognizable name, and paste the subscription URL. Save it, then update that group or use the update-all command. Group controls may appear in a menu or a list toolbar depending on the build; the key is to save the URL before updating. Pasting the URL without updating usually will not populate the server list, and adding a name alone will not create nodes.

When the update finishes, check the log and confirm which group the list belongs to. A successful response with an empty list may mean the content format is unsupported, the URL returned an error page, or a filter is hiding all servers. Clear the search and filters, then select the right group before deleting any existing configuration. If the same URL works on another device, compare client capabilities and update times to help distinguish a compatibility issue from a network retrieval failure.

How subscription updates affect manual edits

A provider may change server addresses, names, or parameters. The next update may rebuild or replace entries according to the client's rules, so edits made directly to a subscription node may not last. To experiment, first copy it as a separate manual node and label its purpose, then change one parameter at a time. After a bulk update, do not assume an old name still refers to the same configuration. Remove temporary copies when you are done so you do not accidentally select expired settings later.

Create separate groups for subscriptions by source or purpose instead of putting everything in one group and relying on names to tell them apart. Search filters narrow the view; they do not delete nodes or change routing. When you select an active server after filtering, confirm it belongs to the intended group. Check again after an update if the active entry changes. For more ways to organize subscriptions, see Subscription Groups and Server Filters.

How to diagnose a failed update

If an update fails, first check whether the retrieval step returned an error. A connection timeout points to a problem reaching the subscription URL; a response that cannot be parsed means you should check whether the server returned subscription data at all. If the client supports direct updates and updates through a proxy, choose the method that fits your current connection. Forcing a proxied update before you have a working proxy can create a loop: you need an update to connect, but a connection to update. If an existing configuration still works, use it to test the retrieval path.

Repeatedly clicking Update is not a fix. Check the subscription account and URL, then review the network, system time, and error log. If the service is temporarily unavailable, keeping existing working entries is usually safer than deleting and recreating them. Before sharing logs, hide the full URL, user IDs, and server details. Use the Subscription Update Failed or Returned No Nodes Checklist to check each item. After making a change, retry once and note whether the error changed.

By the end of this section, at least one group should update successfully, you should be able to find a configuration in it, and you should know how to set it as the active server. A successful subscription update and a successful node connection are separate outcomes. The first confirms that configuration was retrieved; the second also depends on the server, protocol, and entry settings. Keep these distinct when you check the system proxy next, so retrieval issues do not get confused with connection problems.

Proxy Modes: System Entry and Connection Checks

A system proxy does not route every app on the device

Select an active server and confirm the core is running before setting the system proxy. In v2rayN, use the system proxy option from the main window or tray menu to configure it automatically; the exact menu label depends on your version. This writes the local proxy address to the system settings. Only apps that honor those settings will use it. Some apps have their own network stack or a fixed proxy setting, so they may connect directly even when the system proxy is enabled.

Clearing the system proxy usually restores the system entry but does not necessarily stop the core from listening. Apps manually pointed at a local port may still use the client. Conversely, quitting the client does not guarantee that every environment automatically clears settings it previously wrote. Check the system proxy, core status, and app settings separately rather than relying on the tray icon. Before quitting, clear the system proxy and exit normally to reduce the chance that apps keep trying to use a local port that is no longer available.

Match an app's manual proxy settings to the listener

For an app with manual proxy settings, the host is usually 127.0.0.1. Enter the client's current listening port and select the matching HTTP or SOCKS type. This loopback address points to your device, not the remote node server. Putting a remote node's port in a regular app's proxy field usually will not work: the app does not implement the node protocol or authentication on the client's behalf. If you need to share the proxy with other devices, you cannot simply reuse the loopback address.

For the first test, choose one destination you can reliably reach. Record the result with the proxy off, then enable the system proxy and try again. An app may retain connection pools or cached pages; fully quit and restart it if needed. Check whether the client logs a connection and confirm its outbound route. If no request reaches the client, check the app's entry rather than changing the remote server. If a request arrives but fails, continue with the routing and outbound connection.

Separate test results from real-world performance

Latency checks, connection tests, and loading a real webpage may use different destinations, protocols, and timing methods. One test result cannot represent every site's speed or guarantee that video, downloads, or real-time apps will work. A failed test needs context too: an unreachable test service is not the same as a node that cannot connect. For a useful comparison, keep the device, destination, and mode the same.

If a browser works but another app does not, check whether that app supports the system proxy, has its own proxy setting, or retains old environment variables. Developer tools, terminals, and desktop apps often have separate settings. Do not add a proxy to every app at once; that makes it hard to tell which entry is taking effect. First get one app working with an explicit setting, then restore other apps' original settings one by one to find conflicts.

If all apps that follow system settings fail after you enable the system proxy, check whether the local port is still listening, whether the active server was removed, and whether the core log shows an error. Temporarily clearing the system proxy and confirming that ordinary network access returns is a useful way to distinguish a local entry problem from a basic network issue. For quick answers, see Frequently Asked Questions. By the end of this section, you should be able to tell whether a request reached the client.

Routing: Rule Order and DNS Conditions

Start with a preset, then add exceptions

Routing classifies requests that have already reached the core, then chooses how to handle them, such as connecting directly, using a proxy, or blocking them. In v2rayN, choose a preset in the routing settings, such as Bypass mainland China (Whitelist). These modes commonly use domain and address rules to select direct or proxied connections, but their coverage depends on the actual rules and data files. A preset name is a hint, not proof that a particular domain matches a specific rule.

For your first setup, keep a preset that fits your needs, test the apps you use, and add only a few clear exceptions. If switching to global proxy lets a destination load, the original rules may have selected a different route, but check the logs to confirm. Do not take that comparison as proof that global proxy is always the best choice: local services, LAN addresses, and some account services may still need direct connections.

Order, scope, and fallback behavior

Rules are commonly checked in order, with the first matching rule determining the result; the exact behavior depends on the core and the configuration generated by the client. Put a specific domain exception before a broader category rule, or the broader rule may match first. When adding a rule, record its condition, outbound route, position, and expected result. Saving a domain without selecting the right route, or placing an exception after a rule that already covers it, can make it look as though the rule is not working.

An exact domain match and a domain suffix have different scopes. If you want to affect only one host, avoid a pattern that covers the entire domain. A site may also depend on separate login, image, and API domains, so a working homepage does not mean all its requests are working. Add only the conditions needed for the failing requests, not a long list of unrelated domains. If you are unsure what syntax a client field expects, check its help text instead of pasting a raw core field into an arbitrary UI.

{
  "type": "field",
  "domain": ["full:example.com", "domain:example.org"],
  "outboundTag": "direct"
}

The example above shows an Xray routing rule object, not a complete runtime configuration. It illustrates the relationship between an exact domain, a domain suffix, and an outbound tag. It only works when added to a complete configuration's rules array and when an outbound named direct exists. The example domain is for illustration. If you manage settings through a GUI client, use its routing editor rather than editing auto-generated files, which may be overwritten at startup or when you switch nodes.

How DNS affects address-based rules

Domain-based rules need the core to see the domain name; address-based rules rely on the resolved address. If an app resolves the name itself and submits only an address, a domain rule may not have enough information to match. The core may also perform additional lookups according to its configuration. Sniffing can help recover domain information for some protocols, but not all traffic, and it may affect compatibility. Do not treat sniffing as a single switch that fixes every routing issue.

To troubleshoot routing, choose one destination and one active server, record the current mode, then temporarily add the narrowest possible exception. Compare the destination and outbound route in the connection log. Clear the app cache and reconnect if needed; existing long-lived connections do not necessarily restart when you save a rule. Remove ineffective exceptions after testing so rules do not accumulate. A stable rule set should have a clear reason for every entry, not rely on adding more rules to preserve a connection that only works by chance.

TUN Mode: Traffic Coverage and Recovery

Enable TUN only after a standard proxy works

TUN uses a virtual network interface and related routing settings to send eligible traffic to the client. It can help with apps that do not support a standard system proxy, but it does not guarantee compatibility with every protocol, network adapter, or environment. Verify a standard proxy first so you can tell whether a failure is in the traffic capture layer. Enabling TUN when the node itself cannot connect usually adds more to troubleshoot without fixing incorrect outbound parameters.

Find the TUN switch and related settings in v2rayN, then check the permissions and components required by your build. Enabling it may require elevated permissions to create an interface or change system routes. Grant only the permissions needed to a client from a trusted source. Organization-managed devices, restricted accounts, and some desktop environments may prohibit these operations. Follow device management policies instead of bypassing restrictions by changing global security settings.

Overlapping entries and routing conflicts

For the first test, keep everything else unchanged and enable only TUN. Whether to keep the system proxy enabled depends on the client's implementation and documentation. Combining two entries may change the request path, so do not toggle both back and forth and guess at the result. Temporarily quit other VPNs, virtual network adapter tools, and software that controls routes. When multiple tools change the default route, it can be difficult to tell which one owns the traffic or how to restore it.

Check LAN access as soon as TUN is enabled: test your router's admin page, printers, file shares, and local development services. If they stop working, check the bypass settings for private addresses, loopback, and local subnets; do not send all local traffic to a remote server. Multi-adapter setups, mobile hotspots, and virtual machine networks also need separate testing because they may use different subnets. Set the scope based on your actual network, not someone else's exclusion list.

DNS, UDP, and app behavior

With TUN, DNS requests may take different paths. An app might use its own encrypted resolver, the system may retain cached results, or a query may bypass the expected entry. First check whether the domain resolves and where the DNS request goes; then check whether routing sends the connection through the intended outbound route. Do not change the DNS upstream, routing mode, and TUN stack all at once. Change one thing at a time so you can return to a known-good state.

Some real-time apps and protocols use UDP. Whether they work depends on the local traffic capture method, core capabilities, node settings, and remote service. A webpage loading in a browser does not prove that UDP works over the same path. Test with the app that has the problem and look for its connection and errors in the log. If only one type of app fails, compare its transport and DNS behavior before deciding that TUN itself is broken.

If the problem continues after turning TUN off, exit the client normally and check whether the system still has a virtual interface, old proxy settings, or another tool managing the connection. Prefer the client's recovery option and restart the system if needed; do not delete unfamiliar adapters or routes. Once basic network access is restored, verify a standard proxy before enabling TUN on its own. Note whether the first failure happened during interface creation, DNS lookup, or the destination connection to narrow down what to check next.

By the end of this section, three things should be true: the apps that need traffic capture work, local network services remain reachable, and the network recovers when you disable the mode. If the first two work but the network does not recover on exit, TUN is not ready to be your everyday default. Treat it as an entry option for a specific need, not a switch every device must have on. This makes your network setup easier to understand and roll back.

Everyday Maintenance: Backups, Updates, and Troubleshooting Notes

Keep configuration backups separate from updates

Once the setup is stable, find where the client stores its configuration and plan backups. Include the subscription groups, manual nodes, routing, and personal settings you need to keep. Whether you can copy the whole directory depends on the installation method. Quit the client before copying so its database and configuration files are not being written. Subscription URLs and user IDs are sensitive; restrict access to backup files instead of syncing them by default to every shared device or public location.

Updating the client, core, subscription, and rule data are separate operations. A client update can change the UI or configuration format; a core update can change protocol behavior; a subscription update changes server parameters; and rule data updates affect classification. When something breaks, identify which kind of update happened most recently. Do not change the client, core, node, and rules all in one maintenance session, or it will be hard to tell what caused the difference.

Compare before and after an update

Before updating, note the installation method, active server, proxy entry, and routing mode, and keep a restorable configuration backup. Quit the client normally before updating so the background core does not hold files open. After the update, test the existing simple configuration first rather than immediately importing complex new rules. Read any configuration migration prompt carefully. A newer configuration format may not work with an older build, so rolling back the program may also require restoring the matching configuration backup.

Set up auto-start and auto-connect only after the basic connection is stable. The network may not be ready when the device starts, so a failed subscription update or connection does not necessarily mean the node is invalid. Check the result of a manual retry once the network is ready before changing the startup order. If Android connections often stop in the background, check the system's battery optimization and background activity restrictions for the client. Change only what is needed; do not disable all device management features for one app.

Read logs by stage

When checking logs, look for the earliest relevant error rather than focusing only on the last line. A port binding failure at startup can make every later app request fail; a subscription retrieval error may not affect existing nodes. Handle connection timeouts, name resolution failures, and authentication or handshake errors at their respective network, DNS, and parameter layers. The same error text can refer to different destinations, so consider the timestamp, target address, and steps you took.

Action: update a specific subscription group
Entry: standard system proxy; TUN off
Symptom: update failed, but existing nodes still connect
Compare: clear the system proxy, then try updating again
Note: keep errors from the relevant time period; remove sensitive addresses

The example above contains no real credentials and can help organize your own troubleshooting notes. When sharing, hide full subscription URLs, server domains or addresses, user IDs, and personal directory names. Redact request destinations in logs if needed. Do not share a cropped error screenshot without context. The client type, operating system, steps taken, and last known working state are more useful than a pile of repeated screenshots and make the issue easier to reproduce.

Routine checks before exit and recovery

Before quitting, turn off TUN if you no longer need it, clear the system proxy, then exit the client normally. If you manually set a local proxy in an app, reset that too; clearing the system setting does not stop the app from connecting to the local port. If problems start after switching networks, first confirm the basic connection works and any sign-in page is complete. Proxy software cannot replace the access steps required to join a public network.

The goal of maintenance is to preserve a known-good baseline: one working server, one clear entry, routing you can explain, and a restorable backup. When something goes wrong, return to that baseline before restoring extra features one at a time. Regularly remove temporary nodes, expired exceptions, and duplicate groups to reduce accidental selections and rule conflicts. If the issue fits a known pattern, check Frequently Asked Questions by symptom instead of starting over with a reinstall every time.

Advanced: Understand Configuration and Test One Change at a Time

Start by defining the problem

Advanced configuration does not mean turning on every advanced switch. It means being able to explain how a request moves through your setup. Start with a specific need: a development tool requires its own proxy, a domain must connect directly, or an app needs TUN. Once the goal is clear, choose the narrowest setting that solves it. If a standard system proxy does the job, there is no need to enable a virtual network adapter, custom DNS, and complex multi-outbound rules just because those options are available.

A useful learning order is to inspect the current settings, understand the generated configuration, test one rule, and only then explore custom configuration. The client usually generates core configuration from the node, routing, and global settings, so the raw file is not necessarily the only source of truth. Find the field behind a GUI option, compare the configuration before and after saving, and check its scope. Replacing the entire runtime file can leave the UI out of sync with the actual configuration and make future maintenance harder.

Understand inbounds, outbounds, and tag references

In a raw configuration, inbounds receive traffic, outbounds establish the next connection, and routing assigns matching requests to an outbound. Tags let these sections refer to one another; tag names do not have any special meaning by themselves. Referencing a nonexistent outbound tag or reusing confusing tag names can prevent the configuration from behaving as expected. When reading an example, find both the definition and its references instead of copying just the rule that looks relevant.

Below is a standalone, minimal Xray configuration example: it creates a SOCKS entry on the local machine and connects requests directly to their destinations. It includes no remote proxy node and is not a substitute for a subscription. The port must be available and must not conflict with a running client listener. Use the example to understand how the fields relate. For everyday use, manage settings through the GUI client; stop the test instance when finished to avoid leaving a duplicate listener running.

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

Test one variable at a time

Keep the app, destination, and network conditions fixed during a test. Change one setting at a time and record its original value. To test a domain rule, do not also change the server and DNS. To see whether TUN affects local services, keep routing unchanged and switch only the entry. If the result is unexpected, restore the original value before designing the next comparison. This may seem slower, but it prevents changes from masking one another and makes it easier to tell what actually helped.

Break complex requirements into small, independently verifiable tasks. First get the app working with an explicit local proxy, then add a destination domain exception, and finally check behavior after switching networks. Define a success condition and rollback for each step. To account for connection pools, DNS caches, and long-lived connections, restart the app or reconnect before comparing results instead of repeatedly saving settings. A simple test configuration you understand is more valuable than a large set of unexplained rules.

Know when to stop and return to baseline

When a problem involves server-side protocol parameters, account status, or remote service restrictions, the client can mainly provide accurate symptoms and logs. Do not keep adding local rules to hide a remote error. When contacting your configuration provider, include the protocol, failure stage, and comparisons you have already run, but remove personal credentials. For features whose support is unclear, check the client and core capabilities instead of assuming compatibility based on similar names.

By the end of this guide, you should be able to explain a problem in terms of the entry, rules, and outbound connection, and know which settings belong to the client, the core, or the server. To go through the connection steps again, return to the quick-start guide. To change installation type, see the client comparison guide and the download page. Keep a simple, working baseline and expand it only as your needs change—that is the best way to use this guide.