V2Ray Setup Guide

Core concepts and connection flow

What the client, core, and server each do

V2Ray is a common name for a proxy technology ecosystem, not a single installer. v2rayN, v2rayNG, and v2flyNG are graphical clients. They store nodes, manage subscriptions, select operating modes, and generate configuration. The core handles the actual connection, while the remote server receives requests that use the agreed protocol. Installing a client only prepares the local software; it does not provide a server or create a working subscription.

Project V provides background on the underlying technology. V2Fly continues the V2Ray core ecosystem, while Xray is a separate, related core implementation. Supported protocols, transports, and parameters vary between cores, so a node’s name alone cannot confirm compatibility. Check the protocol, transport, security layer, and any additional parameters. A client interface may let you save a field without the selected core supporting that particular combination.

Break a connection into four steps

To understand a connection, trace it through four steps: the app, the local entry point, the routing decision, and the remote outbound. The browser first decides whether to send a request to a proxy. The client receives traffic through a local listening port or virtual network interface. Routing rules then choose a direct, proxied, or blocked outbound. Finally, the proxy outbound connects to the remote service. If any step fails, a website may not load, but the fix depends on where the failure occurred.

For example, if a browser works but another app cannot connect, first check whether that app uses the system proxy; don’t switch nodes right away. If the client log shows no corresponding request, the traffic probably never reached the local entry point. If the log shows a request followed by a failed remote handshake, check the server address, port, and security parameters. If the connection succeeds but domain resolution fails, troubleshoot DNS separately rather than blaming the connection route for everything.

Tell protocols, transports, and security layers apart

VMess and VLESS are proxy protocols; TCP and WebSocket are transport options; TLS and REALITY relate to secure transport. They are not interchangeable choices at the same level. The full set of parameters must match: even with the right protocol, an incorrect path, server name, or public key will prevent a connection. A REALITY public key and short ID are not subscription passwords. Don’t reuse values from another node or guess them based on a client prompt.

A node address may be a domain name or a numeric address. The address used to connect can differ from the server name used for the security handshake. The remote port identifies where the server listens; the local port is the client’s entry point on your device. They are not interchangeable. A loopback address refers only to the current device, so entering it on another device will not point to the original client. Sharing access over a local network also requires configuring the listening address, firewall, and access controls.

Each stage in this guide includes a verification point: check that the core starts during installation, that nodes are complete after importing a subscription, that requests appear in the logs when testing a proxy, and that routing uses the expected outbound. Record results in this order instead of changing several switches at once. For unfamiliar terms, see the glossary, then return to the relevant setup step.

Choose a client by platform and core

Start with v2rayN on desktop

For Windows, macOS, and Linux desktops, start by considering v2rayN. Identify your operating system, confirm your processor architecture, and then choose the package type. Architecture determines whether the program can run on your device; package format determines how it is installed. These are separate requirements. Use the platform information on the download page and check your system details rather than guessing from the device’s appearance or purchase date. Platform labels in an archive name are not universal indicators.

Windows offers two release options: Desktop and WPF. Desktop uses a newer cross-platform interface, while WPF retains the classic Windows interface. Settings, runtime requirements, and features may differ, but node parameters must still match the server. For a first setup, choose one option from the download page and verify that it connects. Avoid running both clients at the same time, as they may compete for ports or repeatedly overwrite the system proxy.

For Android, check protocol requirements before package architecture

For Android, v2rayNG is the primary option and uses the Xray core. If you need the V2Fly route, consider v2flyNG. Don’t assume the two clients offer identical features just because their names are similar. For nodes that use specific secure transport parameters, first confirm that the client and its core support them. If you already have a working subscription, rely on the provider’s protocol details rather than guessing from abbreviations in node names. Ask the source for missing required fields; don’t assemble parameters by hand.

The download page offers arm64 and universal packages. Most newer devices use arm64, but check the actual architecture on older or specialized devices and in emulators. A universal package may suit devices with an uncertain architecture or a range of devices, though it is generally larger. If the system says the app cannot be installed, don’t keep tapping Install. Check system compatibility, package architecture, and whether the package conflicts with an installed app’s signature or installation source.

Consider the core only after checking parameter compatibility

Switching cores is not a universal speed boost. A node may fail because parameters are missing, a subscription was parsed incompletely, or the network is unreachable; changing cores may not help. Before switching, note the node’s protocol, transport, security layer, and error, then check what the new core supports. Some clients let you choose a core for each node; others use a fixed core. Check the current settings rather than following menu instructions for another platform.

On macOS, check the chip type in About This Mac, then choose the Apple Silicon or Intel download. On Linux, confirm both the distribution’s package system and architecture; deb and rpm are different package formats, not alternate names for the same file. The desktop environment, permissions, and system proxy implementation can also affect how the client works. A successful download only means you have the right package; desktop apps may still need to be configured to use the proxy. Verify this in the next stage.

Once you’ve chosen a client, use one main client while learning and note where it stores data, how it runs, and how it exits. If you need to migrate, back up the original configuration first, then check subscriptions, routing, and DNS one by one. Copying nodes alone does not transfer all settings. See client comparisons for more details. All installation downloads are on the download page; this guide does not provide installers.

Installation and first-run checks

For desktop installs, choose the right folder and permissions

On Windows, follow the installer prompts, or fully extract a portable release to a fixed folder before launching the main program. Don’t run it from an archive preview or extract only the executable; the core and required resources may still be inside the archive. Choose a manageable folder that the current user can write to, and avoid locations with strict protection for files that need frequent updates. If a permissions prompt appears, first identify the operation that needs permission.

If the app reports a missing runtime on first launch, distinguish a graphical interface dependency from a core startup failure. Requirements may differ between WPF and Desktop; follow the current release notes and system prompt. Don’t install a supposed fix from an unknown pop-up, and don’t assume every startup failure means a runtime is missing. If the interface opens but the core exits, check the logs for the specific reason. Common causes include missing files, invalid configuration, a port conflict, or a system restriction.

Installation requirements on macOS and Linux

On macOS, choose the disk image for your chip, follow the window prompts to move the app into Applications, and launch it from there. Handle security prompts through the relevant option in System Settings; don’t disable system-wide protections just to launch a client. If the app cannot be opened, first check that the file matches your device, installation completed, and the system’s stated reason. Don’t jump straight to terminal commands that bypass every check.

On Linux, choose deb or rpm to match your distribution and use its package manager to handle dependencies. If the installer reports dependency conflicts, fix the package state rather than copying library files from another distribution. A standard proxy setup generally does not require running the entire graphical client with elevated privileges. Virtual interfaces or routing changes may require additional permissions. The permissions and method depend on the package, so follow the prompts from your current client.

Install and authorize the app on Android

Before installing on Android, check the package architecture. If the system requires permission to install apps from the current source, grant it only to the source you’re using. An app with the same name that’s already installed may not be replaceable because of a different signing key or a downgrade restriction. Uninstalling deletes app data, so first check whether you can export your configuration. When you first connect, Android asks for permission to establish a VPN connection. This authorizes the client to capture traffic; it does not confirm a remote handshake or guarantee that a node works.

If another app on the device is using the VPN interface, you’ll usually need to stop its connection before starting this client. Battery management can affect background operation, but don’t grant every permission at first install. Test a foreground connection first, then adjust background activity and battery restrictions if you see disconnections. System notifications, the VPN indicator, and the client status can help confirm whether the process is running; verify with a request test and logs as well.

After installation, check that the interface opens, confirm the core starts, note the local listening address and port, and look for another client using the same port. You can check local status even before adding a node. If you change the port, update any manual proxy settings in your apps as well; otherwise, they will still use the old port. Use the port shown in the current client, not a number from another guide as a fixed standard.

Finally, check how the client exits. Some desktop clients keep running in the system tray when you close the window; use the tray menu to exit fully. Some settings also clear the system proxy on exit. During initial setup, exit and relaunch once to see whether the proxy is restored as expected. For more on Windows releases, see the WPF and Desktop installation guide. Don’t add routing or TUN settings until installation is stable.

Import and update subscriptions; check node parameters

Tell subscription URLs and single-node links apart

A subscription URL retrieves a group of nodes. Usually, save it to a subscription group and update the group to fetch its contents. A single-node link describes one connection and can be imported from the clipboard or a QR code. Each has its own import flow. Pasting a subscription URL into a single-node form, or using a node link as a subscription source, can result in an empty list or a parsing error. Before importing, check the provider’s instructions, format, and client compatibility.

In v2rayN, open subscription group management, add a group, enter a recognizable label and the subscription URL, save, and then update it. In v2rayNG and v2flyNG, open subscription group settings from the sidebar. Menu labels may differ, but the sequence is the same: create a group, save the URL, fetch its contents, and check the nodes. If you saved the URL but haven’t updated the group, an empty list doesn’t mean the subscription is invalid. There’s no need to uninstall the client.

When an update fails, distinguish fetching from parsing

Update failures generally fall into two categories: the URL can’t be reached, or the returned content can’t be parsed. For an unreachable URL, check the device’s network, subscription validity, URL completeness, and whether the request requires an existing proxy. For a parsing error, check whether the response is a login page, a webpage message, or an unsupported format. If the client offers an option to update through a proxy, use it only when an existing proxy works. Enabling it before you have a working node can create a dependency loop: the update needs a connection that the subscription is supposed to provide.

After a successful update, check the protocol, server address, remote port, and secure transport fields. Don’t rely on a node’s display name alone. Entries for the same region may use different transport combinations, and similar names don’t make them interchangeable. If imported nodes have obviously missing fields, check the subscription format and client compatibility first. Don’t copy a server name, path, or public key from another node to experiment. The parameters must match as a set.

Keep manual nodes separate from subscription nodes

Subscription nodes are usually regenerated at the next update, so manual changes may be overwritten. To test a field, copy the node to a separate manual group and label it as a test copy. Keep the original subscription as a reference, so copies don’t get mixed together. Before deleting a group, check whether its nodes will also be deleted and whether any settings still refer to that group or a selected node.

When choosing a node, use the client’s connection test for an initial check, then test with the actual target app. Different tests may check only port reachability, a handshake, or a single request; none guarantees how every app will perform. A blank result, a test timeout, and a completely unusable node are different outcomes. Check subscription provider guidance for usage limits, status, and region selection. The client cannot supply missing server access or reactivate a disabled service.

If the node list suddenly becomes empty, first check the selected group and filters, then review the update history. You may have switched groups, or the source may have returned an empty response temporarily. Keep a recent working backup instead of deleting and recreating every group. If some nodes work and others don’t, compare their protocols and transports before repeatedly updating the entire subscription. If all nodes fail, then check the local setup and subscription status.

After every update, confirm which node is selected. If the old node was removed, the client may not automatically select the one you expect. For help choosing a node, see how to compare latency, multipliers, regions, and protocols. You’ve completed this stage when you have a fully configured connection for further testing and know which subscription group it came from—not merely when the list contains entries.

System proxies and app traffic capture

A system proxy is an app convention, not full-device traffic capture

A desktop system proxy tells apps that follow the setting to send requests to a local proxy. It does not capture traffic from every program or change how each app handles networking. Browsers are usually easy to test; some games, command-line tools, and built-in networking components may ignore the system proxy. If a browser works but another app doesn’t, first check whether that app uses the proxy. Don’t assume the client has failed. You can try the app’s own proxy settings or consider TUN if needed.

Common v2rayN system proxy options include Clear system proxy, Set system proxy, Do not change system proxy, and PAC mode. Clear usually removes the system proxy address but does not stop the core. Set system proxy points the system to a local entry provided by the client. Do not change preserves the current system setting; it does not establish a connection. Before choosing, check whether the system already has a manual proxy or another app managing its settings to avoid overwriting them.

PAC and core routing make decisions at different levels

PAC uses an automatic proxy configuration script to tell apps that follow it whether to connect directly or use a proxy. If the app sends a request directly at this step, the request never reaches the client core, so the core’s routing rules cannot process it. Core routing applies to requests that have already reached the local entry point. You can combine the two, but that adds variables when troubleshooting. For an initial test, use one clearly defined traffic entry method and consider PAC only after confirming the connection works.

For an app-level manual proxy, check the entry protocol. HTTP and SOCKS may use different ports, or the client may provide a single mixed-protocol entry; use the current listening settings. A loopback address connects only to a client on the same device. If the browser has a saved old port, its manual setting may take precedence even after the system proxy changes. A browser extension may also control proxy settings, so use one source of control during testing.

Android VPN mode and routing

Android clients receive traffic through the system VPN interface. Whether this covers every app also depends on per-app rules and routing settings. The VPN indicator means the interface is established; it doesn’t mean every request goes through the remote proxy. Excluded apps may keep using their normal network path, and destinations routed directly can still use the local network. When troubleshooting an app, check both its traffic scope and the core’s outbound logs instead of relying on the connection toggle alone.

For testing, choose a reliable target you can reach. After connecting, make a new request and check whether it appears in the client logs. A cached browser page may display without a new network request, and an existing long-lived connection may keep using its old path. Make a fresh request and reconnect. If there’s no request in the logs, check the traffic entry point. If a request appears but fails, check the outbound. If it succeeds but the content is wrong, investigate the target service and DNS.

Before exiting, know which app manages the system proxy. If the client stops while the system still points to its local port, apps that follow the proxy may lose connectivity. Clear the stale system proxy or restart the client; there’s no need to reset all network settings. When switching clients, stop the previous connection and check the system state first to avoid one app clearing a proxy address another app just set.

This stage is complete when you’ve confirmed that requests from the target app reach the client. Don’t add complex routing yet. For a straightforward setup, return to the connection and verification steps in Getting Started. If a mode’s name doesn’t match the traffic it captures, see the Help Center. The next stage covers how the core chooses an outbound for traffic it has received; traffic capture and routing are separate settings.

Routing rules, DNS, and match order

Understand how inbound, rules, and outbound fit together

Requests that reach the core need routing to determine where they go. Rules are usually checked in order; the first match sends traffic to the specified outbound, and later rules don’t handle that same match. A broad rule near the top can therefore hide more specific rules below it. Before making changes, check which outbound tags the client generates and how unmatched traffic is handled by default. UI labels such as “proxy” and “direct” may not match the actual tags in the configuration file.

Direct means the current device connects to the destination; proxy uses a configured remote outbound; block rejects the traffic. These are not quality levels. Proxying a local network service can make printers, router admin pages, or local development servers unreachable. Sending a destination directly when it needs a remote outbound can also produce a different result. Create rules for a specific purpose rather than pointing every entry in the same direction.

Read the fields in a minimal rule

This Xray-style routing snippet sends a specified set of domains and private addresses through an outbound named direct. It is not a complete configuration file that can replace your client’s setup. A matching outbound must exist at runtime, and the core must have the relevant rule data. If the client manages routing, add an equivalent rule in its routing interface to avoid conflicts between manual settings and generated configuration.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy describes how routing handles domains and IP addresses during matching. IPIfNonMatch allows the core to resolve an address after no domain rule matches, then continue checking IP-based rules. It does not mean every DNS request automatically goes through a proxy, or that the same setting controls resolution in every app. Cores and clients may have separate DNS settings. After changing the routing strategy, verify DNS resolution and the actual connection path separately.

Domain and IP rules have different limitations

Domain rules require the core to know the destination domain. If an app connects directly to an IP address or the request arrives without domain information, the intended domain rule may not match. Sniffing can help identify information in some protocols when conditions allow, but it cannot identify all traffic or replace correct DNS and traffic entry settings. Check the logs after enabling it; a rule’s name alone does not prove it is working.

DNS problems often look like failed domain access despite a reachable IP address, but that is only a clue. Secure connections may also depend on a server name, so connecting directly to an IP address may not be equivalent. Check first whether resolution returns a result, then whether a connection to that result succeeds, and finally whether the security handshake works. Don’t change the DNS resolver, enable sniffing, and adjust routing all at once. If the problem disappears, you won’t know which change fixed it.

Maintain routing rules with three principles: exceptions first, clear scope, and changes you can roll back. Add one narrow rule, make a new request from the target app, and check the match in the logs. Expand it to a domain group only after confirming it works. Rule data also affects group matching, so if behavior changes after a client update, check both the data and configuration—not just the interface options. For a deeper look, see inbounds, outbounds, and routing, explained section by section.

TUN mode and system routing

When to use a virtual network interface

TUN receives system traffic through a virtual network interface and passes it to the client or relevant core components. It’s useful for apps that ignore the system proxy and have no proxy settings of their own. TUN changes how traffic reaches the client; it won’t fix incorrect node parameters or reactivate an expired subscription. If a system proxy already meets your needs, you don’t need TUN for the sake of a more complete setup. More traffic capture layers make permissions, DNS, and routing harder to troubleshoot.

Before enabling TUN, make sure a node works in ordinary proxy mode and note your current system proxy, routing mode, and DNS settings. If the connection already fails, enabling TUN will mix a basic connection problem with system traffic capture. Some releases may require an additional service, virtual interface component, or authorization. Support depends on the client, operating system, and selected core. A toggle in the interface does not mean every system requirement is met.

Enable TUN one step at a time

Stop other programs that may change routes or use the VPN interface, then enable TUN as prompted by the client. If authorization is requested, confirm the source and action; don’t use elevated privileges to fix every ordinary startup failure. After startup, check the core and interface logs for permission errors, device creation failures, or failed route changes before testing the target app. If the interface hasn’t been established, switching nodes repeatedly won’t help. Resolve the local traffic capture requirements first.

For your first test, don’t combine the system proxy and TUN without a clear reason. Some clients coordinate both, but combining them manually can create duplicate paths and confusing logs. Start with one traffic capture method, then restore other settings one at a time. Test local network services and ordinary network access as well as the remote destination, to make sure traffic capture hasn’t broken paths that already worked.

Understand outbound loops and private network exceptions

The client needs to connect to the remote server over the regular network. If that outbound traffic is captured by the virtual interface again, it can create a loop. Mature implementations usually handle interface binding, route exclusions, or similar safeguards, but manual route changes and other network tools can still break them. Symptoms include repeated connections, a connection that immediately times out, or all access failing after TUN is enabled. First turn off TUN to restore a baseline, then check for routing conflicts.

Set clear boundaries for local network access as well. Router admin pages, printers, remote desktop, and local development environments may need private addresses to connect directly. If they stop working after you enable TUN, check private address rules, local network bypass options, and virtual interface routes instead of sending all traffic through the proxy. Address ranges may differ across networks, and corporate networks have their own policies. Follow your network administrator’s requirements and don’t overwrite existing routes without a reason.

DNS and UDP also need testing. A successful TUN startup doesn’t guarantee that every domain lookup follows the expected path; an app’s own encrypted DNS settings may change behavior. Whether real-time communications or games work over UDP also depends on the core, node, and server. A working webpage doesn’t prove they will work. Record the results for web access, DNS, and the target app separately instead of treating one test as proof for every scenario.

If network access doesn’t recover after you turn off TUN, stop the client normally, check the system proxy and active VPN connections, and see whether the virtual interface is still active. Use the client’s stop or restore feature first; don’t delete network adapters in bulk. Keep a record of your settings before enabling TUN, and restart the system if needed to check for leftover state. This stage is complete when you can explain the traffic capture scope, test the target app, and return safely to ordinary proxy mode—not just leave the toggle on.

Routine maintenance and layered troubleshooting

Keep a recoverable setup before updating

Treat client, core, subscription, and rule data updates separately. They change different things, so don’t apply all of them at once when troubleshooting. A client update may change the interface or how configuration is generated; a core update affects protocol support; a subscription update changes node sources; and a rule data update changes routing matches. Record the current working setup, update one component as needed, and verify it before moving on. That way, you can identify where a problem started.

Back up at least your subscription groups, manual nodes, routing and DNS settings, and app traffic capture scope. Use the client’s export feature when available. If you copy the data directory, stop the client first so the backup doesn’t include partially written files. Backups may contain access credentials, so store them securely. When moving to another client or release, don’t assume their internal configuration formats are compatible. Reimport standard node details if needed.

Start by identifying the failing layer

When a connection fails, first check whether the local network can still access ordinary sites. Next, confirm that the client core is running. Then check whether the request appears in the logs. There’s no need to test remote nodes if the core hasn’t started; if no request reaches the logs, check the proxy or VPN traffic capture. Once a request reaches the core, check the remote connection, DNS, and handshake. This separates requests that never arrived from requests the core received but failed to process, reducing pointless changes.

A timeout in the logs means a particular wait did not finish in time; it does not automatically identify the cause. A connection address timeout may involve the network path or server status. A handshake error may involve the server name, key, system time, or protocol combination. A resolution error points to DNS checks. Read the target and operation stage in surrounding log lines rather than searching for a single error word. When sharing logs for help, keep the error type and order of events, but hide node credentials and personal network details.

Narrow down the issue with controlled comparisons

Change one condition at a time when testing. Keep the client and mode the same, then try a known-working node to see whether the issue is node-specific. Keep the node the same and switch to another working network to check whether the current connection matters. Keep the network and node the same, then restore default routing to test custom rules. If you change the network, client, and subscription at once, a successful result won’t tell you which change helped.

Keep system time synchronized using a trusted system time service, especially when certificates or time-based authentication are involved. A significantly incorrect clock can make otherwise valid parameters fail. A stale system proxy is another common issue: after the client exits, its local port is no longer listening, but apps keep sending requests to it. Restore the system proxy settings first. Don’t delete all your nodes or reinstall the operating system to fix this.

Raise the log level only when needed for troubleshooting, then restore the normal level to avoid retaining excessive access details. If you can only share a screenshot, include the relevant lines before and after the error and describe the current mode; a screenshot of “connection failed” alone provides little context. For node timeouts, see the seven-point checklist. For general help, visit the Help Center. The goal of maintenance is to preserve a stable baseline and make every change traceable and reversible.

Read configurations and plan your next steps

Read generated configuration before writing your own

After completing the earlier stages, the next step is not to pile on more rules but to understand the configuration the client generates. Find the local inbound, remote outbound, direct outbound, routing, and DNS sections, then follow the tag references to see how they connect. The interface is an abstraction for easier setup; the configuration file shows the instructions the core actually receives. If they differ, check that the file belongs to the currently running instance. Don’t draw conclusions from an old configuration.

Inbounds define how and where traffic is received; outbounds define how to connect to a destination or remote server; routing links them through tags. A tag is just a reference name in the configuration; it does not bind anything automatically. If you rename an outbound tag from an example, update every rule that refers to it. Valid syntax does not guarantee correct logic: a rule may parse successfully but never match because a broader rule takes precedence. Verify behavior with a request test.

Learn parameter constraints with a narrow rule

This rule is useful for learning domain matching: full: matches an exact domain, while domain: matches the specified domain and its subdomains. The example uses a reserved documentation domain. To add it, place the rule in an existing routing rules array and make sure the direct outbound exists. It is not a full configuration and contains no remote connection details. Focus on rule order, match conditions, and tag references rather than replacing the original file.

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

Before trying a custom configuration, check whether the client regenerates the file at startup. If it does, direct edits may work only briefly and be overwritten the next time you save a setting. Use the client’s custom configuration, routing management, or template feature, and find out whether it merges with or replaces interface settings. When multiple sources manage the same field, the final value can be hard to predict. Reduce duplication so each setting has a clear owner.

Learn protocols as needed

For protocol fundamentals, start with the basic differences between VMess and VLESS, then learn how security layers and transports combine. Don’t infer speed or stability from the protocol name alone; actual performance also depends on the server, network path, and app. REALITY, TLS, and WebSocket each have their own requirements and use cases. Study them using a node from a known source and review its parameters one by one; don’t assemble a new connection from fields in random examples. For a basic comparison, see the VMess and VLESS guide.

Then explore DNS policies, rule sets, sniffing, and per-app traffic scope. Start each topic with a testable goal, such as keeping local network services direct or routing one app through a specified outbound. Write down the expected result before configuring it, then check whether the rule matched and where any failure occurred. If you can’t explain what an option is expected to change, leave it at its default for now. Advanced options are not a checklist of features you must enable.

For long-term use, keep a brief change log: what you changed, which problem it was meant to solve, how you tested it, and how to undo it. If behavior changes after an update, compare your change log and running configuration before rebuilding the whole setup. When moving to another device, verify the system proxy, permissions, and interface scope again. Node parameters may be identical, but operating systems can handle traffic differently. Redact sensitive fields before sharing configuration snippets.

The complete learning path comes full circle: understand the connection flow, choose the right package, import and manage subscriptions, distinguish traffic capture from routing, verify and roll back TUN, and use logs to check custom rules. You don’t need to start from scratch every time; use the page navigation to return to a stage. To rebuild a minimal working connection, go back to the quick-start guide, then restore only the settings you need. This helps prevent old configuration from becoming the next source of problems.