v2rayN Setup Guide

Stage 1: Core Concepts

The client, core, and remote service

Think of a connection as three separate parts. v2rayN is the graphical client: it stores nodes, manages subscriptions, builds configurations, and launches the core. The core listens on local ports, handles protocols, resolves domains, and selects an outbound. The remote service receives connections and forwards requests. Installing the client does not provide working nodes, and adding a subscription does not guarantee that the remote service is available. Check each layer separately when troubleshooting to avoid mistaking a remote outage for a client setting issue.

Understand how Project V, V2Fly, and Xray relate. Project V is the broader ecosystem of related tools and protocols; V2Fly continues V2Ray's development, while Xray is a related core fork. A client can connect through different cores, but support for a protocol does not guarantee support for every transport and security combination. A successful import only means the configuration was recognized. Check that the selected core can parse the generated fields and negotiate successfully with the server.

Follow a request through the connection

Start with a request from an app. A browser that uses the system proxy connects to a local listening port. The core receives the target domain or address and applies the routing rules to choose a direct, proxy, or blocked route. A proxy outbound then connects to the node server and completes the relevant handshake. With TUN, traffic enters through a virtual network interface, but it still needs routing and a working outbound. Changing how traffic enters cannot fix an incorrect server address, credentials, or transport settings.

Read node settings in groups. The server address and port define the destination; a user ID or password authenticates the connection; the transport specifies how data is carried; and TLS or REALITY settings define the corresponding security handshake. VMess, VLESS, Trojan, and Shadowsocks are distinct protocols. REALITY is not a subscription format alongside them. Use the complete parameter set provided by the service; don't swap fields just because their names seem similar.

Set clear troubleshooting criteria

Distinguish DNS resolution, transport connectivity, and the app's response. A resolution failure may mean the request never reached the node. A refused connection usually calls for checking the local listener or remote port. A handshake error points to security settings or the system clock. An error page may come from the destination service itself. Don't lump every symptom under “the proxy isn't working.” Note the affected app, destination, time, and mode, then check the core log for the same moment.

Know what connection tests can and can't tell you. A test in the node list only checks the method used by the client; it doesn't prove that every site, app, and network will work. Restrictions on a probe target can make a test fail even when real traffic works. Conversely, a successful test doesn't prove that DNS, persistent connections, and file transfers all work. Keep one real website and one real app as test cases.

To finish this stage, describe the request path without relying on menu labels: which app sends which destination through which entry point to which core, and which outbound sends it onward? Once you can answer that, use the Concepts at a Glance to fill in any unfamiliar terms. The remaining sections follow this path. You don't need to memorize every protocol field or pile on complex rules before the first connection works.

Stage 2: Choose a Client

Start with the operating system and processor

For desktop use, start with v2rayN, then visit the client download page for your operating system and processor architecture. On Windows, check System type under Settings → System → About. On macOS, check the chip or processor under About This Mac. On Linux, confirm both the distribution's package format and the machine architecture. Don't choose a package based only on the computer brand, or assume similar-looking interfaces mean packages are interchangeable.

In the Windows download section, choose between the desktop edition and the classic WPF edition. The desktop edition uses a cross-platform interface and suits users who want a similar experience across desktop systems. The WPF edition is for Windows and retains the classic interface and workflow. Check the requirements for the specific package you choose. Don't assume a feature is available just because an edition is newer or classic; menus, settings, and runtime requirements can vary by release.

Match core capabilities to your existing configuration

On Android, v2rayNG, which uses the Xray core, is the first choice; v2flyNG, which uses the V2Fly core, is an alternative. Choose based on the protocols and features your existing nodes require, rather than installing more clients and switching between them. Don't assume the two apps have identical settings. Similar import workflows don't mean their configuration databases can be copied directly. For your first setup, follow the Android Quick Start and keep just one active network interception method.

Separate client features from subscription contents. Switching clients won't turn a standard node into a different security configuration or supply parameters the server doesn't provide. If fields are missing after import, check which client the subscription targets, whether it provides complete links, and which core the node requires. Don't delete parameters just to make an import succeed; a simplified configuration may not reveal incompatibilities until the handshake.

Keep a working setup you can fall back to

Before switching desktop editions, note the subscription groups, active node, listening ports, routing mode, and DNS settings in the old setup, then export a backup if the client supports it. Treat the new setup as a separate installation and test basic access with one node first. Don't run two clients that compete for the same listening ports, or let them alternately change the system proxy; the displayed mode may then differ from the address actually in use.

When checking system requirements, distinguish launching the interface from handling traffic. The main window can open even if the core failed to start; a running core doesn't guarantee that the current account can create a virtual network interface. A standard system proxy usually doesn't require running the entire program as an administrator. TUN may need elevated permissions or a dedicated service mechanism. Grant permissions for the feature you need instead of treating elevation as a universal fix.

Once you've chosen, write down the operating system, processor, client, and planned traffic entry mode. Check the requirements for that platform on the download page so you don't have to change plans halfway through installation. To compare desktop editions, see v2rayN Desktop vs. WPF Edition. Focus on platform support and feature differences, not just appearance.

The goal of this stage is choosing the right package, not enabling every feature. Start with a simple, repeatable connection that meets your device and node requirements. Add capabilities only when you need broader app coverage or different routing; this makes problems much easier to isolate.

Stage 3: Install and Launch

Choose a stable folder and check prerequisites

Choose the confirmed edition from the Windows client downloads, then follow the instructions for the package format. Run an installer through its setup wizard. If you have an archive, extract it to a stable folder before launching the app; don't run it from inside the archive window. Avoid storing persistent data in a location that gets cleaned up. The app needs to save settings, logs, and core files, so write access matters more than a short folder name.

If the app reports a missing runtime component on first launch, install the one specified for that release. Don't follow an old guide and install a mismatched architecture. Note the exact component named in the message, and distinguish a missing runtime from a blocked file or a core startup failure. If Windows displays a security warning, verify the source and file properties before proceeding. Don't disable system protection or allow every unknown app just to open the interface.

Check that the interface and core both start

After opening the main window, locate the log or information panel. With no nodes added yet, a connection failure is expected; look instead for configuration read errors, unwritable paths, or listener failures. A responsive interface only confirms that the GUI is running, not that the core is listening. After adding a node, check the startup messages again. Make sure the core doesn't exit immediately or keep restarting before configuring the system proxy, so the browser isn't pointed at a port that isn't working.

In Settings, find the local listener options and note the address, port, and supported entry protocols. Some versions provide a mixed listener; others offer separate HTTP and SOCKS listeners. Don't infer current default ports from an old article. Usually, only apps on the same device need access through the loopback address. Enabling LAN access expands who can connect. Turn it on only when other devices need to use the listener, and consider firewall rules and access controls.

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess

These commands list current TCP listening ports and process IDs; they don't change network settings. Compare the ports with your notes from the interface, then find the matching process under Details in Task Manager. If another app is using a port, first close any duplicate client instance. If you need both clients running, change one listener port and update any apps that depend on it. Don't end an unfamiliar process just because you don't recognize it.

Save a startup baseline and a way to exit cleanly

Temporarily disable startup launch, automatic subscription updates, TUN, and other extra features. First verify a manual launch and exit. Before quitting, clear the system proxy; afterward, confirm that the browser can still access the internet through its usual route. This verifies your recovery path if a node later stops working. Closing the main window may only minimize the app to the tray, so use the tray menu to confirm that it has fully exited.

Use the same acceptance checks on other desktop systems: the app starts, data can be saved, the core loads, listeners don't conflict, and exiting restores the network. On macOS, choose the installer for your chip; on Linux, use the package format for your distribution. For permission issues, check the install location and system message rather than loosening permissions on every file. To investigate a port conflict, see How to Fix a Local Port Conflict.

After this stage, keep a brief note of the install location, backup method, and listener settings. Restart the client once and confirm that your settings persist. A stable baseline makes later changes to subscriptions and routing easier to compare, without confusing installation problems with network changes.

Stage 4: Subscriptions and Node Management

Add a group, then update it

Open Subscription Group Settings, add a recognizable group name, and paste the subscription URL into the corresponding field. Check for leading or trailing spaces, line breaks, and punctuation copied by mistake. Subscription URLs may contain access credentials; treat them as sensitive and keep them out of public screenshots, notes, and support requests. Save the group, return to the main window, select it, and choose Update current subscription (without proxy).

Understand the difference between update methods. Without proxy is usually for when this device has no working proxy yet, or the subscription URL is directly accessible. Updating through a proxy depends on an already-working route. If a direct update fails, first check whether the URL is reachable on the current network, then decide if an existing proxy is needed. Don't expect an update through a proxy to solve first-time access when no working node is available; that creates a dependency loop.

Tell retrieval failures from parsing failures

When an update fails, first check whether any content was retrieved. DNS errors, connection timeouts, and server refusals happen during retrieval. If content arrived but no nodes appeared, the format may be unsupported, the response may actually be a login page, or the node parameters may not be recognized. A page loading in a browser doesn't prove that it returned subscription data. When contacting the service provider, share the error type and a redacted description of the response, not the full subscription URL or credentials.

After a successful update, check each node's name, protocol, address, and group. Identical names don't mean identical configurations, and a name doesn't tell you how well a node performs. Select one node as the active server, then check whether the core loads it successfully. Avoid testing many nodes at once; parallel tests can consume bandwidth, trigger service limits, or mask real-world reliability with short-lived results.

Avoid losing manual changes when subscriptions update

To add a single share link, use the client's clipboard import option, then check the imported fields. Manual nodes work well for temporary tests or a small number of configurations; subscription groups are better for updates managed by a service provider. Don't assume edits to subscription nodes will persist: the next update may recreate them. For long-term customization, copy the node to a separate manual group and label it clearly as no longer synced with the original subscription.

Before deleting a group, check whether the action affects the group record, its subscription nodes, or all servers. Keep test groups separate from your everyday group. Fewer nodes after an update doesn't necessarily mean the import broke; the provider may have removed entries. Check the update result and group filters before concluding that another group was selected by mistake. Restoring an old backup can recover local records, but it can't make an unavailable remote service work again.

Keep security-related settings consistent as a set: server address, port, user ID, transport, server name, and the corresponding key parameters. Don't disable certificate verification just to clear a handshake error, and don't copy security fields from one node to another. An inaccurate system clock can also break handshakes; correct the device time before testing again. Only edit fields manually when you know what the server requires.

Set update frequency according to how often the provider changes its configuration. Updating more often won't automatically improve speed and may overwrite settings you're troubleshooting. Back up local data before important changes and note the active node. After an update, retest against the same destination. This helps distinguish changed subscription content from a temporary connection failure while preserving the details needed for troubleshooting.

At the end of this stage, you should be able to explain where the subscription comes from, which group contains a node, which record is active, and what the next update may overwrite. If a basic import fails, repeat the subscription steps in the Quick Start Guide. If a parameter is unclear, check the glossary rather than repeatedly deleting the client's entire data folder.

Stage 5: System Proxy and Proxy Modes

Separate the traffic entry point from outbound routing

Start by separating two questions: how an app hands a request to the client, and how the client sends it onward. Auto-configure system proxy handles the first; global or bypass rules in routing handle the second. Enabling the system proxy doesn't mean every app will use it. Choosing global proxy only affects traffic that has already reached the core. Understanding these layers explains why a browser might work while some desktop apps remain unchanged.

In v2rayN, choose Auto-configure system proxy, then check the actual address and port under Windows Settings → Network & Internet → Proxy. They should match the listener currently used for the system proxy. Don't rely on the tray icon alone. The address should usually be the local loopback address, not the node server address. The remote node port is for the core's connection to the server, not the local proxy port to enter in a browser.

Choose a traffic capture method based on app behavior

Start by testing a real destination in a browser that you know uses the system proxy. A browser with its own proxy, proxy extension, or separate profile may ignore system settings. For troubleshooting, leave only one proxy source enabled and note the original settings before disabling any conflicts. Command-line tools, games, and background services may use their own network stacks; check their settings rather than assuming that browser success applies to every app.

If an app needs manual proxy settings, enter the HTTP or SOCKS listener it supports, using the address and port the client is actually listening on. Don't swap the fields for the two protocols. If the client offers a mixed listener, make sure it supports the protocol you selected. If the app has a separate DNS setting, check whether it sends resolution requests through the proxy; otherwise, the connection may use the proxy while DNS follows a different route.

Know what clear, keep, and auto-configure mean

Clear system proxy removes the current manual system proxy setting, but doesn't clear proxy settings inside individual apps. Don't change system proxy means the client won't modify the system setting; it doesn't mean no proxy is currently configured. If websites stop loading after you exit the client, first check whether the system still points to a local port, then check for a separate browser setting. Don't use an entry point when the client that listens on it is closed.

Note the current state before changing modes. After switching, check the system settings and test a new connection. Existing long-lived connections may keep using the old route, and browser connection pools can delay the effect. Close and reopen the test page; if necessary, fully quit and relaunch the app. Don't change the node, DNS, and routing between tests at the same time, or you won't know which change affected the result.

At the end of this stage, verify both directions at least once: enable auto-configuration and confirm the browser works through the local listener; clear the system proxy and confirm the original network behavior returns. Keep these steps as a recovery procedure. Move on to TUN only when an app doesn't honor the system proxy and you actually need to capture its traffic—not just to turn on every available option.

Stage 6: Routing and DNS

Start with a built-in routing mode

First, select a built-in routing mode that fits your needs, such as bypassing mainland China, then test real traffic. Rule sets may differ in their handling of private addresses, domain categories, and default outbounds, so don't infer every detail from a mode's name. Review the rules and their order. Check whether local network resources go direct, where unmatched destinations go, and whether the referenced rule data files load correctly.

Understand rule order. Many routing systems check rules from top to bottom, so a broad match near the top may prevent more specific rules below it from running. Before adding an exception for a service, determine how it interacts with existing rules and place it appropriately. Don't put a catch-all proxy rule at the top and expect a private-address direct rule at the bottom to work. After a change, check the logs to see which rule matched; a page loading doesn't prove the rules are correct.

Separate domain rules from address rules

Domain rules match domain information available in a request; address rules match the destination IP address. A service may use many domains and distributed addresses, so adding only its home page domain may miss login, static assets, and downloads. Conversely, a rule for one resolved address may affect unrelated services sharing it. Prefer clearly defined domain patterns for the service instead of treating a single DNS result as a permanent rule.

{
  "type": "field",
  "domain": ["geosite:cn"],
  "outboundTag": "direct"
}

This is a rule object, not a complete configuration. It belongs in the appropriate core configuration's rules array. The environment must also have usable domain-category data, and the outbound tag must be named direct. The client may generate a different tag, so inspect the generated configuration and adjust accordingly. Don't replace the entire configuration file with this snippet, or paste it into an import field that only accepts share links. Use the client's supported rule editor whenever possible.

Align DNS resolution with the traffic route

DNS converts domain names into addresses, but the core, operating system, and apps may each resolve names independently. Remote DNS and direct DNS serve different purposes; entering the same address twice doesn't create split routing. If the remote resolver needs a proxy to be reachable, make sure that connection has a clear outbound route. Otherwise, resolution may depend on the proxy while the proxy connection depends on a resolution that hasn't completed—a startup loop.

When troubleshooting, first find out which component resolves the domain, then check the route used for the DNS request. A browser's encrypted DNS may bypass the expected system resolver. An app that connects directly to an IP address may leave the core without the original domain. Sniffing can extract protocol information in some cases, but it doesn't identify every connection or replace a complete DNS design. If routing behaves unexpectedly, simplify the path and restore features one at a time.

When a rule matches unexpectedly, note the full domain, resolved address, rule order, and active outbound. After rule data updates, the category assigned to a domain may change; treat the update as a configuration change. If a temporary exception fixes the issue, identify the root cause before keeping it instead of accumulating patches that override one another. See DNS Leak Testing and Prevention for checks on the expected resolution path.

At the end of this stage, you should be able to explain three outcomes: explicit direct routing, explicit proxy routing, and the default behavior when no rule matches. Check that the rules persist after a restart and that the core reports no unknown fields or missing data. Enable TUN only after routing and DNS work reliably with the system proxy; otherwise, a wider capture scope can spread a local issue to more apps.

Stage 7: TUN Mode and Traffic Capture

Decide whether you actually need a virtual interface

TUN captures eligible system traffic through a virtual network interface. It's useful for apps that ignore the system proxy but still need to follow shared routing rules. It changes the traffic entry point; it doesn't give a node new protocol capabilities or fix invalid credentials. Before enabling it, make sure the same node already works with the standard system proxy and keep that working setup as a baseline. If the basic connection is unstable, troubleshoot the subscription, listener, and routing first.

When assessing traffic capture, consider local, LAN, and remote destinations separately. Printers, shared folders, development services, remote desktops, and other virtual networks may need specific direct routes. TUN doesn't mean every address should use the proxy. Decide how to handle private addresses and required subnets before enabling it. Don't wait for a remote administration session to drop before considering how to restore connectivity; remote access especially calls for a local recovery method.

Start in the right order: permissions, interface, then routes

Save your settings, then use administrator privileges or the relevant service mechanism required by your client. Enable TUN mode and follow the prompts for the specific interface and core. After turning it on, don't immediately conclude that it failed because a site won't load. Check first that the core is still running, the virtual interface exists, and the system routes have been applied. Handle permission errors, interface creation failures, and route update failures as separate issues.

If you see an interface or driver error, first close duplicate client instances and check whether other virtual networking software is using related resources. Don't delete every virtual adapter from the system or uninstall drivers in bulk; some belong to virtual machines, containers, or corporate networks. Start by disabling TUN and restarting the client. Then address the specific component named in the error and keep a record of each step.

Test TCP, UDP, and DNS behavior

First test a website that worked through the system proxy, then test an app that wasn't previously captured. Both should work to confirm that the new entry point is doing its job. For apps that use UDP, voice, or real-time communication, verify that the remote service and protocol combination support the required traffic. Working web access doesn't guarantee UDP works. An app starting successfully doesn't prove that its media connections follow the same route; test the actual operation.

Treat DNS as a separate layer when troubleshooting TUN. System resolution, encrypted DNS in an app, and virtual interface capture may all interact. If connections by IP work but domain access fails, check the resolution chain, access to the remote resolver, and possible routing loops first. Don't mask DNS problems by permanently pinning an address or clearing every DNS setting. Record the current values, then compare them with the configuration options supported by the core.

If you can't reach a LAN device, check its address, subnet mask, and current routes before adding a domain exception. A shared service accessed by IP won't match a domain rule. If another network tunnel is running, route priority and the default gateway may compete. Disable nonessential entry points one at a time to compare results, then restore the combined setup and identify which combination caused the conflict instead of blaming the node.

After waking from sleep, switching Wi-Fi networks, or plugging in Ethernet, recheck the virtual interface and DNS path. If the connection doesn't recover, try turning TUN off and on again so the client can rebuild its state. If that fails, check the new logs instead of repeatedly elevating permissions. After a normal exit, confirm the network recovers; after an unexpected exit, also check the system proxy and routes. For more detail, see v2rayN TUN Mode Setup Notes.

Success in this stage doesn't mean the switch stays on. It means newly covered apps work, direct-access resources still work, and you know how to recover. Keep TUN only if it meets a real need. If the system proxy already covers your use cases, stick with the simpler entry point to avoid unnecessary interactions between permissions, interfaces, and routes.

Stage 8: Maintenance and Troubleshooting

Treat backups and updates as separate tasks

Make a backup while the connection is stable. Include subscription groups, manual nodes, routing, DNS, and any essential custom settings. Use the client's export feature and note what isn't included. Backups may contain subscription credentials and node identity details, so store them securely and redact them before sharing. Saving only the app files isn't enough to restore a working setup, and a screenshot of node names can't recover the full configuration.

Separate client, core, subscription, and rule-data updates; each changes something different. Update one at a time and verify after each. Exit the client normally before updating it so files aren't in use. Afterward, check the menus, listeners, and configuration migration. If the package manages core components centrally, use its supported process. Don't overwrite core files with versions from another source; the interface may generate fields the core can't handle.

Troubleshoot from the entry point to the destination

When a problem occurs, stop changing settings and note the last change made before it started. Check in order: does the app use the entry point, is the local listener active, is the core running, does DNS resolve, does the node complete its handshake, and does the destination respond? Move on only after each layer passes. This narrows the issue to a specific boundary instead of changing nodes, refreshing subscriptions, and resetting the network all at once and losing a reproducible test case.

If the browser fails but other apps work, check its independent proxy, extensions, encrypted DNS, and cached connections. If every app fails, start with the listener and core logs. If only one destination fails, check the destination itself, domain rules, and distributed resources. If it fails only on a different network, compare DNS, network authentication, and routing. Classifying the issue is more useful than repeatedly clicking connection tests and can prevent unnecessary configuration resets.

Get-Date
Resolve-DnsName example.com

These commands show the current system time and system DNS results; they don't test the core's remote DNS. Use them for comparison: if system resolution fails but the core resolves successfully, the two paths differ. System DNS working doesn't prove that the proxy outbound works. If you see a handshake error, check the system clock, time zone, and synchronization status too. A successful command doesn't prove the entire proxy path works; test with a real app as well.

Record a minimal reproduction and recovery steps

When reading logs, look for the first relevant error rather than later cascading timeouts. Note the component, destination type, and time, then compare them with the sequence of actions. Before sharing logs, remove full subscription URLs, user IDs, passwords, and other sensitive fields. When showing rules, include only the relevant snippet and outbound relationship. Higher log levels may record more activity; once troubleshooting is complete, restore an appropriate level and delete unneeded copies.

Verify a backup restore instead of assuming a successful import fully recreated the environment. Check that the groups are present, then confirm the active node, listener ports, routing, and DNS. Finally, check the system proxy or TUN. Interfaces, permissions, and install paths from the old setup may not apply to a new device, so configure them for the new system. Keep the current backup during restoration; don't overwrite the only working setup with an old configuration of unknown origin.

Mobile troubleshooting also needs checks for battery optimization, startup behavior, and background restrictions. A connection that drops after the screen locks isn't the same issue as a desktop listener conflict, so don't reuse desktop troubleshooting steps. See v2rayNG Background and Battery Settings for a device-side checklist. Whichever client you use, keep a recoverable configuration before updating, and verify network behavior separately from software changes.

At the end of this stage, prepare a short recovery checklist: clear the system proxy, disable TUN, confirm the original network, start the client, load the baseline node, and restore routing. Following a checklist during an outage makes troubleshooting more consistent than searching for scattered tips and helps prevent a local problem from spreading across the system.

Stage 9: Advanced Configuration and Learning Path

Start by reading the generated configuration

Advanced work starts with reading what the client actually generates, not writing a full configuration from scratch. Find the option to view the active configuration and identify the inbound, outbound, routing, DNS, and logging sections. See how they correspond to the interface settings. Generated files may be rebuilt when the app starts or the active node changes, so direct edits may not persist. Learn the client's custom configuration and merge options before deciding what to manage through the interface.

Practice tracing an outbound tag. Find the actual tags for the proxy and direct outbounds, check that routing rules reference the right tags, then confirm the default behavior when nothing matches. A tag is an internal configuration reference, not a fixed label or node remark. Map the tags before copying rules from another source. A configuration with valid fields but a missing tag may fail at startup or choose an unexpected outbound.

Define the expected result of every experiment

For each experiment, write down the goal, change, and rollback plan. For example, if a specific domain should go direct, expect that domain to match the intended rule while other destinations remain unchanged. If you enable TUN for an app, expect its new traffic to reach the core while local resources remain accessible. Be specific enough to know what to test. Judging complex settings by whether they “feel faster” can't rule out the effects of caching, node changes, or network fluctuations.

Keep a separate configuration copy for experiments instead of layering changes onto your everyday setup. Test a single exception rule before combining several; understand basic DNS behavior before exploring more advanced domain handling. If a new problem appears, return to the most recent working version and compare changes instead of adding another patch. Keep notes detailed enough to explain what every custom field does when you return to the setup later.

Choose your next steps based on the problem

The protocol path is useful if you often run into import or handshake problems. Learn server addresses, authentication, transport, security layers, and server names in order, and understand which settings must come from the remote service. Don't treat protocol names as a performance ranking or assume one combination is generally better based on a single test. The server's capabilities and your network conditions determine what's viable; the client can only use configurations within its compatibility range.

The routing path suits users who need to reach LAN resources, direct services to different outbounds, or handle complex apps. Start with rule order and the difference between domains and addresses, then learn about category data and default outbounds. The DNS path follows who makes a lookup, which outbound carries it, and how the result affects matching. These paths need to be tested together, but change them separately at first; a single change in access may involve both DNS results and routing rules.

The system networking path is for users who need TUN long-term. Learn about interfaces, routing tables, address ranges, and permission boundaries, and understand why network changes, virtual machines, and other tunnels can conflict. Don't enable LAN listening just to gain more features, and don't share a local port without understanding its reach. Exposing a service to other devices also means assessing authentication, device trust, and firewall rules; that's more than a local proxy setting.

Build a configuration you can maintain

When tidying the final configuration, remove temporary exceptions that are no longer needed. Add a brief reason for every rule you keep, and note its dependencies on core features and data files. More rules don't mean better coverage; overlapping rules make the configuration harder to understand. Don't keep blocks of parameters you can't explain. If a block is necessary, prove what it fixes in an experimental copy before merging it into the long-term configuration, then confirm it still works after a restart.

Use a consistent reading path: return to the Quick Start Guide when you forget a step, check the Concepts at a Glance when a term is unclear, read the technical articles for a specific error, and visit the client download page when switching platforms. This guide connects those resources; you don't need to enable everything at once. The goal is a working setup you can explain, verify, and recover, then extend as real needs arise.