Advanced Configuration Guide

Subscription Groups & Server Filters

Subscription groups are for organizing sources, not choosing network routes. A group stores a subscription URL, update options, and related filters; each server entry contains its protocol, address, and port. Moving an entry to another group does not automatically change its route. Likewise, selecting a group tab usually changes which entries are shown, not which server is active. Before making changes, distinguish the group you are viewing from the server you are connected to, so an update does not lead you to misread the connection status.

Create groups you can track

In v2rayN, add a group from the subscription management area. Give it a note that identifies its source and purpose, then paste the complete subscription URL. Depending on the interface layout, the option may be in a menu or toolbar. Subscription URLs often contain personal access credentials; never include them in public screenshots, support discussions, or shared documents. Add one group first. After a successful update, check that the list contains the expected protocols and complete addresses before adding other sources. This makes it easier to pinpoint problems.

Choose the update method based on your current connection. “Update without proxy” works when your network can reach the subscription URL directly; “Update through proxy” requires a working proxy connection. If you have not imported a usable server yet, routing the update request through a proxy can create a startup dependency. Check whether the URL opens directly, or use a single share link from the provider to establish the initial connection before trying a proxied update. An update failure does not mean every server is unavailable.

Filtering a list vs. changing its contents

Server filters generally work in one of two ways: list search hides rows that do not match, while import filters may determine which entries are added to the local database. They apply at different stages. First use list search to confirm that your keyword matches the intended entry, then set an import filter for the group. If the interface explicitly supports regular expressions, you can filter by alias with a regex. If it only supports plain text, regex syntax will not work as a universal input. Check the current interface documentation for field names and matching behavior.

Research|Work
^(Research|Work)-

The two lines above show regex patterns for “contains either keyword” and “starts with the specified prefix.” They are alternatives, not settings to enter together. The first matches broadly; the second requires aliases to follow a consistent naming pattern. Test on a small number of entries first, checking case sensitivity and whether matching applies to the entire string. If the list is empty, clear the filter and update again. Repeatedly changing the subscription URL usually will not fix an empty list caused by a filter.

What to check after an update

Updating a subscription may recreate server entries, so manually edited aliases, transport settings, and notes may not be retained. If you need to maintain custom entries, put them in a separate manual group and note why you changed them. Avoid patching provider-supplied parameters in an auto-updating group and relying on the changes long term; the next update may overwrite them. If the source configuration appears incorrect, check with the provider instead of enabling unfamiliar parameters one by one.

In v2rayNG, manage sources under “Subscription group settings,” then run an update; menu names vary by version. Android has different clipboard permissions and network access conditions from desktop, so a URL that updates successfully on a computer may not be reachable from the phone's current network. As an alternative using the V2Fly core, v2flyNG requires a separate check of protocol and extension-field support. Seeing an entry appear in the list does not guarantee that all connection parameters are compatible.

After updating, check that the group still contains the expected entries, confirm whether you need to reselect the active server, and then run a real connection test. This establishes an actual connection; it is not the same as checking whether a host responds. Batch tests may also use traffic, so start with a small selection and check the logs if results look wrong. For trade-offs between latency and server multipliers, see the server selection guide. Do not choose an exit for every task based only on list sorting.

Routing Rules in Practice

Routing rules determine which outbound handles a connection that has reached the core. They do not decide whether every application sends traffic to the core in the first place. Applications not covered by the system proxy generally will not be intercepted just because you add a routing rule. First test a rule in a browser that respects the system proxy, then consider TUN. In v2rayN, use the “Routing” section to choose a preset or edit rules. Presets named “Bypass mainland China,” for example, represent specific policies; inspect their rules rather than assuming from the name how every domain will be handled.

Understand match order and outbound tags first

Common Xray and V2Fly routing rules are evaluated in order; the first match determines where traffic goes. A broad rule near the top can prevent more specific rules below it from being reached. A rule object with domain, port, and network conditions generally requires all those conditions to match; multiple entries in the same domain array are alternatives. Start by testing one explicit domain rule, then add port or address conditions gradually. This helps avoid confusing “and” with “or.”

This example shows the structure of Xray / V2Fly routing fields and the order for sending private addresses and a reserved example domain directly, then proxying everything else. It assumes your existing configuration defines outbounds named direct and proxy. Client-generated tags may differ, so adjust the example to match your actual configuration. The reserved domain is for demonstration only; replace it with real business domains when setting up split routing.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

Test domain and IP matching separately

Use full: for an exact domain, domain: for a domain and its subdomains, and regexp: for a regular expression. Text without a prefix may be treated as a substring, which can match more than expected. For a single fixed site, prefer a clear exact or suffix match. Business pages may also load separate login, static asset, and API domains. Opening the home page does not prove that every part of the service followed the same route; check the relevant requests in the logs.

AsIs generally matches using the destination information already available. IPIfNonMatch attempts to resolve a domain when no domain rule matches, so address rules can be checked. IPOnDemand may resolve a domain when a rule requires address information. These strategies change when resolution happens during routing; they do not set a single DNS resolver for the browser. For rules based on geographic IP data, also check how domains are resolved, whether the data files are available, and whether the connection still includes domain information.

Where presets end and custom rules begin

Geographic domain classification relies on the relevant data files; it is not a live network test. Missing data may prevent startup, while outdated data may produce unexpected classifications. First check which rule resources the client is using, then update them through the client’s own tools. Do not paste syntax from another routing engine: even if both use domain and region names, their fields, matching behavior, and data formats may be completely different.

After changing a route, close existing connections in the test app and try again. Browser connection reuse, app connection pools, and caches can make new rules appear ineffective. Change one rule at a time, open the relevant logs, and confirm the new request’s destination and outbound tag before restoring other traffic. To proxy all traffic that is already intercepted, adjust the routing fallback. To intercept apps that do not normally use the proxy, see the TUN section below. These are separate concerns; “global” is not a useful substitute for checking each one.

Keep local network access requirements in mind when writing rules. Printers, home storage, and corporate intranet sites may use private IP addresses or internal domains. Allowing private IPs alone may not fix an internal domain that cannot resolve; allowing a domain alone may not cover an app connecting directly to an address. First identify how the service is accessed, then configure DNS and routing together. For common connection patterns, revisit the connection checks in Getting Started to establish a baseline.

DNS Configuration

DNS issues often look like “the proxy is connected, but the page still won’t load,” yet not all domain lookups use the same resolver. The operating system, browser, app, and proxy core may each have their own cache and resolution path. Before changing settings, map the request flow: does the app send a domain to the local proxy, or resolve it to an IP first? Does the core route by domain, or does it need to resolve the address first? Knowing where a domain becomes an IP tells you which setting to change.

Distinguish three kinds of DNS lookups

First, the proxy server’s own hostname must be resolved before the proxy connection can be established, using a resolver that is already reachable. Second, the target domain may be resolved locally or remotely. Third, routing may perform a lookup to match IP-based rules. Pointing all three to a resolver that itself requires the proxy can create a startup dependency loop: the client needs the proxy to resolve the server address, but the proxy is not yet connected.

Before changing “DNS settings” in v2rayN, check which core and configuration mode are active. Some options generate Xray configuration; others apply to the network component used by TUN. Similar labels in the interface do not necessarily write to the same field. In v2rayNG, “Enable local DNS” affects local resolution and should be understood alongside the actual remote DNS and direct DNS options. Do not enable multiple DNS interception features at once without knowing what each one affects.

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["domain:example.com"],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

This Xray / V2Fly-style DNS snippet shows how to choose a resolver by domain and set a regular resolver for other queries. Whether that resolver is reachable depends on your network. localhost means to use the system resolver; it does not require a separate DNS server to be running on the machine. skipFallback keeps this server from handling fallback queries for domains it is not assigned to; it does not prevent every retry after a lookup failure. This snippet affects core DNS only, not every app.

Encrypted DNS still depends on correct routing

With encrypted DNS, consider how the resolver’s hostname is initially resolved, which port it uses, and which outbound handles the request. Encrypted transport cannot make an unreachable network reachable or replace routing rules for business traffic. If the resolver is only accessible through a proxy, make sure the proxy server itself does not depend on that connection path before it exists. For a working setup, change only the resolver for business domains and test it first. Consider intercepting system DNS only afterward, to avoid introducing several dependencies at once.

Check IPv4 and IPv6 together. Receiving an IPv6 address does not mean your network and selected outbound have a usable IPv6 route. Requesting IPv4 only may work around the issue temporarily, but it does not fix IPv6. If some sites time out, check the returned address family, the address actually used for the connection, and the route it takes. Support and field behavior for UseIP, UseIPv4, and UseIPv6 depend on the core in use; do not copy settings between components without checking.

Check each cache layer after changing DNS

After changing DNS, restart the relevant client network components, then close existing connections in the test app. Clear the system and browser caches if needed. If the browser uses its own Secure DNS, test requests may bypass the system resolver; note whether it is enabled when recording results. A command-line lookup only reflects the resolver path used by that command. It does not automatically show what the browser, chat app, or proxy core resolved.

Preserve the existing resolution path for corporate intranet domains. Public resolvers usually cannot resolve internal names, so replacing them everywhere may restore public sites while breaking office systems. Keep internal domains on the system or corporate resolver and route their addresses directly. If the network supplies internal DNS dynamically, do not hard-code an address observed once; recheck after switching office networks so a local setting does not cause problems elsewhere.

A good troubleshooting order is: check that the proxy server’s hostname resolves, confirm that business domains return the expected address family, verify which outbound handles the request, then inspect connection errors. Change DNS only if resolution is actually unexpected. Certificate name mismatches, handshake failures, and account authorization errors need to be addressed in their respective connection settings; repeatedly switching resolvers usually will not help. For virtual IP mapping, see the FakeDNS section.

TUN Mode

TUN mode uses a virtual network adapter to receive IP packets, often to cover apps that ignore system proxy settings. It is a separate feature from “automatically configure system proxy,” and does not mean all traffic will be sent to the proxy server. The adapter and system routes determine which connections are intercepted; routing rules then decide whether intercepted traffic goes direct or through a proxy. Troubleshoot TUN in two steps: check whether packets enter the interception path, then identify the outbound selected for them.

Establish a system proxy baseline first

With TUN off, use the system proxy to load a web page and run a real connection test. Confirm that the server settings work, then note the active server, routing profile, and DNS settings before enabling TUN. If the system proxy cannot connect, turning on TUN only adds variables. The TUN implementation in v2rayN depends on the platform and build; it may use a component separate from the main proxy core. Xray routing snippets cannot be used as another component’s configuration without conversion.

A virtual network adapter and system routes usually require appropriate permissions. Windows may require elevation, macOS may request network-related authorization, and Linux needs device access and route-management permissions. If TUN fails to start, check the logs to see whether the adapter was created and routes were added before deciding whether the issue is permissions or network settings. Do not run the client as administrator at all times as a default fix; check the permission flow supported by your build and the specific error first.

Prevent routing loops and double interception

After system traffic is intercepted, the proxy’s own connection to the server must be able to leave the interception path. Otherwise, it may be routed back into the proxy itself. Well-designed clients typically handle this with interface binding, route exclusions, or process protection, but multiple adapters, other VPNs, manual routes, and firewall rules can disrupt it. If enabling TUN immediately disconnects you, pause other traffic interception tools, leave only one client running, and compare routes and logs before and after.

Enabling the system proxy and TUN together is not necessarily a problem, but it makes the traffic path harder to understand. Some apps connect to a local proxy port; others send traffic straight to the virtual adapter. For troubleshooting, start with just one interception method, confirm it is stable, then decide whether both are needed. On Android, v2rayNG and v2flyNG generally use the system VPN interface to intercept traffic. Another VPN app in the same user space may compete for authorization; a “started” status in the app is no substitute for testing the network.

App scope, local network access, and UDP

The “per-app proxy” feature in v2rayNG determines which apps are included in or excluded from VPN processing. Check the description of the current mode: selecting apps does not always mean “proxy only these apps,” because include and exclude modes work in opposite directions. Start with one test app, fully close and reopen it, and check whether it appears in the client logs before expanding the list. System components, download managers, and embedded web views may make requests from different processes, so test the actual service you need.

Local network discovery, printing, and casting may rely on broadcast or multicast; a single direct rule for private addresses may not restore them. First check whether that traffic should enter TUN, then see whether the client offers a local network bypass. Real-time communication and games often use UDP, and a successful web test does not confirm that UDP works. Check local interception, outbound protocol, and server support together. A protocol’s UDP support does not guarantee UDP will work on every network.

MTU determines the maximum payload size of an individual packet. Consider changing it only when you have evidence such as a specific large request stalling or a connection that establishes but transfers data unreliably. Record the original value and test changes gradually. An arbitrarily low MTU can reduce performance and hide other problems. Rule out DNS issues, unreachable outbounds, and double interception first; there is no single MTU value that works for every platform and network.

When shutting down, turn off TUN in the client before quitting, then confirm regular network access has returned. If a crash leaves the network unusable, reopen the client and shut it down normally, check system proxy and virtual adapter status, and reconnect to the current network if needed. Do not delete unfamiliar system adapters or clear all firewall rules. For macOS authorization issues, see installation and network permission guidance. If the client fails during startup, troubleshoot the client itself first.

FakeDNS

FakeDNS returns virtual addresses for local mapping, not the real public IP address of the destination server. After an app receives a virtual address and connects to it, the interception component uses the mapping to recover the original domain, then routes by domain or passes the connection to a proxy. This preserves domain information only when both the DNS query and subsequent connection pass through a path that shares the mapping. Simply enabling an option called FakeDNS does not establish the full path.

First decide whether virtual address mapping is needed

If an app already sends the full domain through a local proxy, the core can usually match it directly, with no need to add FakeDNS as an “optimization.” FakeDNS is better suited to connections intercepted at the IP layer when you need to recover domain information. Whether to enable it depends on the interception method and client support, not just on the presence of an option. FakeDNS in one component and fake-ip in another may have similar names but different configuration fields, address pools, and cache behavior.

This example shows how an Xray / V2Fly-style configuration relates an address pool, DNS, and inbound sniffing. It is not a universal configuration for every v2rayN TUN implementation, and it does not include a complete inbound or outbound. Merge only the relevant parts into a custom configuration after confirming that the active core supports the fields and handles DNS queries. When using a client GUI toggle, prefer letting the client generate the configuration rather than manually adding a conflicting second setup.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "metadataOnly": false
  }
}

The second snippet belongs inside the inbound object that needs to restore the mapping; it cannot be placed anywhere in a complete configuration. The address pool must match the interception routes and avoid conflicts with the active network. The example uses a dedicated test range, not public service addresses that apps can reach directly. poolSize is the mapping capacity, not a server count or performance guarantee. If the client manages the mapping pool, keep its default unless a specific issue calls for a change.

How mapping, caching, and traffic sniffing work together

Regular traffic sniffing tries to identify a domain from the initial connection data; FakeDNS recovery relies on an address mapping created earlier. They are not interchangeable. Some protocols and encrypted handshakes do not expose a recognizable domain, so sniffing may fail. If the mapping is gone, a virtual address alone is not enough to infer the original domain. In v2rayNG, understand “Enable traffic sniffing” in the context of the active core; it is not a universal switch for recovering any connection’s destination.

A common edge case occurs when the client restarts and loses its mappings while apps still cache old virtual addresses. Those apps keep connecting to addresses the current core cannot resolve, so some fail until they are reopened. Close old connections, clear relevant DNS caches or restart the test app, then look up the domain again. Restarting only the proxy while leaving all app connections open can prolong the mismatch and produce inconsistent troubleshooting results.

Preserve real DNS for applications that need it

Some programs compare resolved addresses, write them into later protocol fields, or use their own resolver to bypass system DNS. Internal discovery and apps that depend on address semantics may also be incompatible with virtual IP responses. If you encounter compatibility issues, restore the real resolution path for the affected domain or app and test the service before adding more sniffing parameters. Internal network domains generally need the internal resolver, not a virtual address for every query.

If a test tool reports that a destination is in the virtual address pool, that does not tell you where the service is hosted. Do not use that address for latency comparisons or as a manually fixed server. Check the actual outbound and remote destination in the logs instead. Conversely, a browser showing a normal public IP does not prove FakeDNS is inactive: the browser may use its own DNS or have a cached result. Start verification with a fresh lookup.

When disabling FakeDNS, handle caches and routes in the right order. Switch back to real DNS and reload the client, clear virtual addresses held by apps, confirm new lookups no longer return an address from the pool, and then check that interception routes behave as expected. If only a few apps fail after the change, check their caches first. If everything fails immediately, check configuration generation, DNS reachability, and the interception path before changing server entries.

Managing Multiple Subscriptions

Managing multiple subscriptions means keeping sources separate, avoiding repetitive edits, and having a clear rollback path when an update fails. More subscriptions do not automatically provide failover or help the client choose the best server for each task. Design source management, active server selection, and business routing separately: sources provide entries, the active server determines the default proxy exit, and routing decides which connections use it. Mixing the three makes updates difficult to trace.

Group by maintenance method, not temporary use

Keep auto-updating sources separate from manually maintained entries. Auto-updating groups should contain provider-supplied parameters; manual groups should contain locally changed entries that have been tested, with notes explaining their purpose and why they were changed. Use stable source names that do not depend on which server is currently active. Express use cases in notes or filters rather than importing the same subscription repeatedly under labels like “work” or “video,” which creates a list of hard-to-compare duplicates.

Do not identify duplicates by alias alone. Two servers with similar names may use different transports, ports, authentication parameters, or service names; different names may still refer to identical connection settings. Before deduplicating, find out which fields the client uses to identify duplicates and make a backup. If you cannot confirm the rules, keep the source groups and use display filters to reduce clutter rather than performing an untraceable bulk delete.

Update schedules and rollback plans

Automatic updates work well for stable parameters and reliable sources, but update frequency should reflect actual needs. Updating too often may trigger provider rate limits or make temporary errors harder to reproduce. After setting a schedule, observe a normal update and check whether existing entries are preserved on failure and how the active server is handled on success. Behavior varies by client and update method; do not assume a failed update can never change local data.

Before a bulk update, make sure you have at least one tested connection path available for recovery. If updates must go through a proxy, keeping the current working entry is especially important. If the source returns empty content after an update, check the response error and filters before clearing every group and trying again. Restore a local backup or re-import a verified source configuration; do not publish an old access URL to ask others to test it. If credentials have expired, ask the provider to issue new ones.

Syncing across devices and choosing a format

When moving between desktop and Android, transfer a subscription URL or a single share link supported by the client rather than copying the entire client data directory. Databases, interface state, paths, and runtime components vary by platform; copying a directory may bring along invalid paths or obsolete permissions. After migration, check the protocol, transport settings, and security options, then run a real connection test. Extension fields supported by v2rayN may not be supported by the core used in v2flyNG.

A Base64 subscription usually wraps multiple share records, while a complete JSON file may contain inbounds, outbounds, routing, and DNS. Importing full JSON as a regular subscription may not extract a server list; importing a share link as a complete configuration will not recreate the original routing setup. If an import fails, identify the content type and the correct client import option first. See subscription formats and share links for examples; changing the file extension alone will not convert the content.

Check the scope when exporting, too. Some actions export selected servers, others export the current group, and a full backup may include every group and setting. Before sending a file to another device you own, check whether it contains sources you do not need to transfer. When retiring an old device, also check exported files, clipboard history, and cloud backups. Deleting entries from the client does not remove subscription URLs saved elsewhere.

Keep a change log instead of repeatedly guessing

For each significant change, record the original routing profile, active core, interception method, and reason for the change. Do not include credentials; the goal is to know which step introduced the problem. If multiple sources fail at once, check shared dependencies first: network access, DNS, system time, client permissions, and the proxy path used for updates. If only one source fails, check its URL, response format, and provider authorization. This preserves more useful clues than reinstalling three clients in turn.

Test backup recovery, too. Confirm you can import the backup, identify manual entries, and restore routing and DNS settings before relying on automatic updates long term. Run recovery tests at a controlled time, not while an office connection is in use. If the desktop client will not start, use the startup crash troubleshooting guide to check the runtime environment first. A damaged configuration and an unavailable source are different problems and should be handled separately.

Custom Outbounds

An outbound is the core component that establishes a connection to its destination; routing sends traffic to it by tag. In everyday v2rayN use, the client typically builds a proxy outbound from the selected server, alongside direct and block outbounds. Manage outbound structures directly only when you need multiple exits, a specialized chain, or a fully custom configuration. First check whether the GUI's server selection and routing rules meet your needs. This reduces the risk of client-generated settings conflicting with local edits.

Start with the smallest structure you can verify

This teaching configuration for Xray / V2Fly contains only a local SOCKS inbound, a direct outbound, and a block outbound. It does not connect to any remote proxy server. The listener is restricted to the local loopback interface so the proxy is not accidentally exposed to your LAN. Use it to understand how inbounds, routing, and outbound tags fit together. To connect to a remote service from a subscription, use verified server parameters rather than guessing authentication fields.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

Unmatched connections in this example go to the first outbound, which is direct; a reserved example domain demonstrates the block rule. Before testing, make sure the listener port is not already in use. Do not start a second instance on the same port. When a client uses a complete custom configuration, whether GUI settings for the active server, DNS, or routing still apply depends on how it was imported. Check the generated configuration or logs rather than assuming all GUI settings are added automatically.

Tag names and default behavior

tag is a local reference name, not a protocol name or a parameter recognized automatically by the server. The outboundTag in a routing rule must exactly match a defined outbound; a spelling mismatch can cause startup or runtime problems. Use clear, unique, short names and document the default outbound order. Do not assume a server alias automatically becomes an outbound tag: the display name in the client list and fields in the core configuration belong to different layers.

Before editing, save a complete working configuration, then check its syntax and startup behavior. JSON does not allow ordinary comments or trailing commas, and an editor accepting the text does not mean the core accepts every field. If logs report an unknown protocol or field, confirm whether the client launched Xray or V2Fly and which configuration layer contains the field. Another network component may also use JSON, but its configuration cannot necessarily be imported as-is. Start with the first valid error; later errors may only be consequences.

Chained connections and multiple outbounds

A chain requires a clear role for each hop: the first reaches the next, and the next reaches the final destination. How one outbound references another, which transports are available, and which fields are supported depend on the core implementation. Simply placing two server objects side by side does not create a chain. Verify each hop independently, then test DNS, UDP, and connection reuse across the combined path. Every added hop introduces another dependency that can break the final connection.

Having multiple outbounds does not automatically enable speed testing, load balancing, or failover. To use a selector or balancing policy, configure its candidates, selection logic, and health checks separately, and confirm that the active core supports them. Desktop users who only need to switch the default server should use v2rayN's existing server selection. Before deploying a complex setup, be clear about the specific problem it solves beyond a simpler configuration.

Verify with a real request

After configuring, verify four layers: inbound listener, routing match, outbound connection, and service response. A listening port only proves that the program started far enough to open it. A successful connection test does not guarantee that every domain or UDP request for the destination will work. Choose a repeatable task, close existing connections, run it again, and record which layer reports an error. Detailed logs may contain destination domains and addresses, so restore the usual log level when troubleshooting is done.

If a custom configuration fails but the client-generated configuration works, revert to the working setup and compare its inbounds, default outbound, DNS, and routing. Do not keep changing subscription authentication parameters. For a custom setup you plan to keep, document the supported core, required resources, and recovery steps locally. See the glossary for core concepts and the client selection guide for how the three clients differ. If you have not established an initial connection yet, return to the Getting Started guide and build a minimal working configuration first.