From V2Ray basics to advanced setup
A complete client configuration guide

Core concepts: understand the configuration layers

What the client, core and server each do

Think of the graphical client as the place where you manage settings. v2rayN handles subscriptions, lets you select nodes, builds the runtime configuration and launches the appropriate core. The core handles protocol connections and traffic forwarding. The server sits at the other end of the connection and must use matching protocol and authentication settings. You can download a client for free, but installing one does not automatically provide a working server configuration. Before you begin, get valid node details or a subscription URL from a source you trust.

Project V is the starting point for this proxy technology ecosystem. V2Fly continues the community development of V2Ray, while Xray follows a related but separate core development path. Some clients can also use sing-box as a proxy core, but sing-box is not another name for V2Ray. Configuration formats, feature support and parameter meanings vary between cores. A graphical interface may present similar options across cores, but that does not mean any configuration can be used unchanged with any core.

Understand protocol, transport and security settings together

VMess, VLESS, Trojan and Shadowsocks are proxy protocols; TCP, WebSocket and gRPC are transport methods. TLS and REALITY involve connection security and should not be confused with protocol names. A node can have the right address and port but still fail if its transport path, server name or security settings do not match. After importing a node, keep its full set of parameters intact. Don’t replace individual values just because their names look similar.

For a VLESS node, check the server address, port, user ID, transport and security settings together. TLS may also require a server name; REALITY requires matching parameters such as the public key and short ID. VLESS alone is not a complete encrypted connection scheme. The security layer and parameter combination must match the server configuration. Don’t try to make it work by mixing in settings from another node.

Trace settings along the traffic path

A typical request passes through several stages: an app makes a request, traffic enters the client, routing rules choose an outbound, the core connects to the server, and the server reaches the destination. System proxy and TUN determine how traffic gets in; routing decides whether it goes direct, through a proxy or gets blocked; node settings determine whether the proxy connection can be established. DNS also resolves domain names and can affect rule matching and the address used for a connection. Keep these layers separate when troubleshooting instead of focusing only on the node list.

The goal of this chapter isn’t to memorize every term. It’s to be able to describe your setup: which client you use, which core it runs, the node’s protocol, how apps connect to it and the default routing mode. Write these down briefly, then change one layer at a time. Look up unfamiliar terms in the glossary. When an error appears, first identify whether it occurred during startup, parsing, the handshake or destination access, then decide what to check next.

Choose a client for your platform and configuration needs

Start with v2rayN on desktop

For Windows, macOS and Linux desktops, start with v2rayN to follow the subscription groups, system proxy and routing steps in this guide. Before downloading, check your operating system and processor architecture, then choose the matching release. The same OS name doesn’t guarantee the same installer will work: x64 and arm64 target different processor architectures. If the app won’t run, first check that the package supports your device instead of switching nodes—the network configuration hasn’t come into play yet.

The Windows download section offers Desktop and classic WPF builds. Desktop uses a cross-platform interface and suits users who want a similar workflow across desktop systems. WPF retains the classic Windows interface for users who prefer it. The main differences are the interface and how each build is distributed; they don’t indicate that one will make a node faster. Check the release notes for runtime requirements, interface details and where settings are saved. Don’t mix program files from the two folders.

For Android, know the primary option and the compatibility alternative

For Android, v2rayNG with the Xray core is the primary option. v2flyNG, which uses the V2Fly core, is an alternative when compatibility requires it. Both clients can import nodes and manage connections, but don’t assume they support every share link, transport setting or advanced feature in the same way. If a configuration depends on a specific core feature, confirm that the target client supports the combination before testing it. Switching apps based on a similar name can make a protocol support issue look like a broken subscription.

Android packages usually come in arm64 and universal variants. For a recent mainstream phone, check whether arm64 is the right fit. If you’re unsure about the architecture or run into compatibility issues, check the universal package’s requirements. Universal doesn’t mean better connection quality; it simply covers a broader range of architectures. Before installing, make sure Android allows installation from that file source. Granting permissions is a separate step after installation—successful installation doesn’t mean the proxy is running.

Compare clients based on what you need to do

Listing specific tasks is more useful than comparing feature counts. If you only need a browser to use a proxy, start by checking the system proxy or the browser’s own proxy settings. If an app ignores the system proxy, look into TUN. If you need to route traffic by app, check whether your platform supports per-app routing. These tasks rely on different system mechanisms. A toggle in the client doesn’t guarantee that your system permissions, network and core support it.

Consider maintenance costs when choosing a client. If a device already has a stable setup, note its subscription source, routing policy and special parameters before migrating, then confirm the new client can reproduce them. Exported files may not transfer directly between clients, so rebuild from the original subscription or a standard share link where possible. See the client selection guide for a detailed comparison, and find installation options on the download page. By the end of this chapter, choose one clear first option, establish a working baseline and then decide whether you need to switch.

Install and launch: establish a working baseline first

Check architecture, install location and permissions

Open the client download page and choose a build for your operating system. On Windows, check the system type in System Information; on macOS, identify the chip in About This Mac; on Linux, check both the architecture and package format. Don’t assume a file is suitable just from its extension. Once the download is complete, install or extract it before launching the main program. If the release is meant to run from an extracted folder, don’t open it from the archive preview—relative paths, resources and saved settings may not work correctly.

On Windows, keep the client in its own folder rather than repeatedly overwriting different builds in the same location. Make sure your user account can save settings there, and verify that changes persist after you exit. Avoid running the client with elevated permissions all the time just for convenience; grant additional permissions only when a feature requires them. If a runtime dependency is missing, install the one identified by the error instead of copying runtime files from another computer.

On macOS, choose the build that matches your chip, place it as directed by the system and launch it. If macOS blocks it, check the file source and the system prompt, then follow the normal authorization flow in Security settings. On Linux, choose the appropriate deb or rpm package and resolve dependencies through your distribution’s package manager. Desktop environments, permission prompts and virtual network interface support vary by distribution. Record startup failures separately from connection failures; they are different problems.

On first launch, check only what you need

Once the main window opens, check that the client saves settings, the core starts and the local listening address and port aren’t already in use. The local listening port is where apps connect to the client; it is not the server’s port. If the log says the address is already in use, close other proxy instances or change the local listening settings, then restart and test again. Don’t kill unfamiliar system processes or run several clients on the same port, as that makes later tests inconclusive.

On the first launch, leave system proxy and TUN off. Import one configuration, then test it with the client’s connection test or an app explicitly configured to use the proxy. This separates core operation from system traffic routing. If the interface looks fine but the core keeps exiting, check the first startup error in the log, especially for incompatible settings, missing resources, insufficient permissions or a port conflict. An open window alone doesn’t show that the background proxy service is running.

Check startup and shutdown once

On Android, the first connection prompts you to grant system VPN permission. The app needs this permission to route traffic through the system network interface; granting it doesn’t mean you’re connected to a server. Confirm which app is requesting access, then check its status. If another VPN session is active, you’ll usually need to choose between them. Desktop systems may also have proxy settings left behind by other network tools. Pause those tools while troubleshooting so an old entry doesn’t interfere with a working client.

Finally, exit the client and reopen it to check that subscription groups and preferences were saved. Then check that the system proxy is restored after exit and that basic network access doesn’t depend on a stopped local listener. Installation is complete when the program launches, settings persist, the core starts without errors and you can clearly tell whether it’s running or stopped. For Windows interface and dependency details, see Windows installation: steps and common issues. Don’t add complex routing until installation is stable.

Subscriptions and nodes: maintain a reliable source for your configuration

First identify what kind of link you have

A subscription URL fetches a set of configurations and can be used again for future updates. A share link usually describes one node, often with a protocol name at the start. Use the right import flow: add subscriptions to a subscription group, and import a single-node link from the clipboard or share-link menu. A URL that opens in a browser isn’t necessarily a subscription; it may lead to an account or information page. Check the source’s instructions before importing. Don’t treat a login page as configuration data the client can parse.

In v2rayN, create a subscription group, give it a name that identifies the source and paste in the full URL. Check that the scheme, path and query parameters are intact, especially everything after the question mark. Don’t include spaces, line breaks or non-ASCII punctuation. Save the group, update its subscription and check whether nodes appear. The group name is a local label, not a server authentication setting. Renaming it won’t fix an expired URL or invalid credentials.

Choose an update method based on whether the URL is reachable

Whether to update a subscription through a proxy depends on your network and whether the URL is reachable. If you don’t have a working proxy yet, try updating without one first. If direct access is affected by the network path and you already have a working node, try updating through it. These are two ways to fetch subscription content, not switches for fixing the subscription format. If the server returns a login page, error page or empty content, changing the route may not help; check URL access and the source’s status.

If an update fails, keep your existing nodes rather than clearing every group. Check the log for a connection timeout, DNS resolution failure, authentication rejection or content parsing error. The first two point more toward the retrieval path; the latter two may indicate an access or format issue. Ask the configuration provider whether the URL is still valid, but don’t post the full subscription URL in public. Query parameters often act as credentials. If they’re exposed, follow the provider’s process to replace them rather than just deleting the message.

After an update succeeds, check that the nodes actually work

A node list appearing means the content could be fetched and parsed; it doesn’t mean every node can connect. Choose a node with complete settings that fits your needs, make it active and test it with a real request. Names in the list are labels and don’t reliably indicate protocol, security settings or availability by region. For a manually maintained node, record its source and purpose. If its provider has stopped offering the service, changing its display name or importing the same link again won’t restore the connection.

Keep subscription nodes and manually added nodes separate where possible. Some clients rebuild a group’s entries when updating it, so special settings edited directly on a subscription-generated node may be overwritten next time. If you need local changes, check whether the client can preserve them or copy the node into a separate configuration and note its source. Don’t assume that subscription updates always replace all local routing settings—or that they never affect the active node. After updating, check your selection and key parameters.

Once you have a reliable source, consider automatic updates. Follow the provider’s usage terms; updating too often may trigger access limits without getting you fresher data. After a major update, check for unusual changes in node count, whether the active node changed and whether a real request still works. For the difference between a single node and a subscription, see share links and subscription URLs. For update problems, follow the subscription update troubleshooting checklist: check the fetch result first, then content compatibility.

Proxy modes: first check how apps connect

System proxy controls the entry point, not traffic routing

The system proxy is a set of network settings that apps can read. When it’s enabled, apps that follow these settings send requests to the client’s local proxy listener. Apps that ignore the system proxy may connect on their own. So enabling it doesn’t route all device traffic through the client, and it doesn’t mean every request uses a remote node. Once traffic enters the client, routing rules still determine where it goes. Keeping the entry point separate from the outbound makes it easier to spot when an app isn’t connected to the client at all.

Common v2rayN options include Clear system proxy, Set system proxy automatically, Do not change system proxy and PAC mode. Automatic configuration points the relevant system settings to the client’s local listener; Clear removes those proxy settings; Do not change leaves the current system settings as they are—it does not force a direct connection. PAC lets compatible apps choose an entry point based on a script. The exact system settings affected depend on the OS and client implementation, so note any existing network configuration before switching modes.

Test the entry point with one app

Keep TUN off, select a working node and start the core, then enable automatic system proxy. Make a new request in a browser known to follow the system proxy and check the client’s access log for the destination. If needed, close old connections or restart the browser to avoid reused connections skewing the result. If no relevant request appears, first check the app’s proxy settings, system settings and local listener instead of switching nodes or changing transport parameters.

If an app lets you enter an HTTP or SOCKS proxy manually, use the listener type, address and port shown by the client. Don’t guess based on example numbers in a tutorial. An HTTP listener can’t be used as a SOCKS listener unless the client explicitly supports a mixed listener and it’s enabled. An app’s own proxy setting may take precedence over the system proxy. Record app-specific settings so you can explain why only some programs are affected.

PAC, global routing and bypassing mainland China operate at different layers

PAC makes some decisions before traffic reaches the client. Presets such as global routing or bypassing mainland China decide the outbound after traffic enters the client. When both sets of rules are active, some direct requests may never appear in the core log because the entry layer already handled them. Start with a single, easy-to-observe entry point, then use core routing rules. If you need PAC, confirm the script source, update method and actual support before using it; avoid stacking several automatic routing systems at once.

Test the proxy with a real request, not just the client’s status icon. A successful connection to one destination proves only that the current path to that destination works. Another app may use a different protocol, DNS path or its own proxy. If a browser works but another program doesn’t, compare how they connect. If some page resources fail, check the routing and resolution of the affected domains instead of assuming everything works because the main page loaded.

A managed work network may enforce proxy settings. Before changing them, check your local permissions and organizational requirements. Don’t overwrite settings in an environment where you’re not allowed to change them. After exiting, waking from sleep or switching networks, check that the system entry point is still as expected. By the end of this chapter, you should know which apps connect through the proxy, where they get the proxy address and how to restore settings after closing the client. Move on to TUN if you need to capture more traffic; don’t assume every system proxy issue is a node problem.

Split tunneling: express what you need with the fewest rules

Start with a preset that gives you predictable default behavior

Choose a routing preset that fits your needs, then add only a few custom rules. Global mode usually sends traffic that enters the client through a proxy outbound, but doesn’t change whether an app enters the client in the first place. Bypass mainland China typically uses domain and IP rules to send some destinations direct; its exact scope depends on the preset and rule resources. Don’t treat a preset name as a complete technical description. Check the actual rules and default outbound, especially what happens to traffic that matches no rule.

Routing rules are generally evaluated in order, and the first matching rule determines what happens next. A broad rule near the top can override more specific rules below it. Before making changes, write down the goal: which domains should go direct, which should use a proxy and which connections should be blocked. Then check that you’re matching on the right criteria. Domain names, destination addresses, ports and app details aren’t always available together. If the entry point provides only an address, adding domain rules alone may not work; check where domain information comes from.

Understand configuration snippets; don’t paste them into a complete runtime file

This Xray-style routing snippet shows basic rules for sending loopback and private addresses direct and a specified domain through a proxy. It is not a complete client configuration, and the referenced outbound tag must exist in the actual configuration. Graphical clients may use different tags. First express the same intent in the interface; if you need a custom configuration, check the documentation for the core you’re using. sing-box has a different rule structure, so don’t paste this snippet into a different core’s configuration.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      }
    ]
  }
}

In this example, a domain suffix rule matches the domain and its subdomains; it doesn’t match any address that happens to contain the same letters. An IP rule only works when the destination address is available and matches. A strategy that keeps the original domain doesn’t actively resolve every domain just to apply IP rules. For LAN services, prefer explicit local domain or address rules and test the way you actually connect. Don’t assume that a private address range will cover every entry point just because you added it.

DNS and sniffing affect what routing rules can see

DNS resolves domain names to addresses; routing determines which outbound a connection uses. They affect each other but aren’t the same setting. Resolved addresses can vary with the network, resolver and time, so replacing a domain rule with a temporary IP address is often unreliable. Sniffing can try to identify destination names from some protocol data, but it can’t identify every kind of traffic and isn’t a universal fix. Understand what it does and check compatibility before enabling it; don’t switch on every related option at once.

To test a new rule, pick a clear destination and record its route before making changes. Add the rule, start a new connection and check the actual match or outbound in the log if available. If the interface only shows connection details, use a controlled destination and check the request result. If traffic still follows the old route, first rule out connection reuse, app caching and rule order; then look into DNS differences. Change one thing at a time and confirm it works before moving on.

Good routing is minimal and clear. Remove temporary rules you no longer need and note why each exception exists. After updating rule resources, retest common destinations and LAN access. If something breaks, restore the last working preset, then add custom rules back one at a time. Don’t sacrifice clarity to make the rules more complicated. A solid result means you can explain the default outbound, exceptions and match order, then prove the rules work with real requests—not just see a saved-settings message.

TUN mode: expand traffic capture on a stable setup

Understand what a virtual network interface does

TUN uses a virtual network interface to receive network traffic routed to it by the system. This can bring some apps that ignore the system proxy into the proxy workflow. It expands the traffic entry point; it won’t fix an expired subscription, invalid credentials or an unreachable server. Before enabling TUN, make sure the same node already works through a basic proxy setup. Otherwise, entry, routing and remote connection problems will be mixed together. For a browser-only setup, you may not need this extra layer.

Desktop systems may require administrator permissions, service support or additional network authorization. The exact process depends on the OS and release. Follow the client’s instructions; don’t download generic drivers from unknown sources. After enabling TUN, check that the virtual interface is up, the core keeps running and the routing settings don’t immediately produce errors. Android clients usually capture traffic through the system VpnService. Its permission prompt is different from a desktop TUN toggle, so don’t follow the desktop steps one-for-one.

Prevent the proxy connection from being captured by itself

TUN must handle connections to the proxy server correctly, or traffic can loop back into the virtual interface. Graphical clients often handle this automatically, but running multiple clients, changing routes manually or using another VPN at the same time can disrupt the setup. When enabling TUN for the first time, pause other traffic-capturing tools and use a single entry point. If logs show repeated connections, requests pile up or the network drops as soon as TUN starts, turn TUN off to restore the baseline, then check the outbound and system routes.

Follow the client’s recommended combination for system proxy and TUN. Using both isn’t necessarily wrong, but it makes the traffic path harder to understand. For testing, you can turn off the system proxy and check an app that normally ignores it, comparing access logs before and after enabling TUN. If the client offers options such as automatic routing, strict routing or interface selection, keep the defaults until you understand them. Options with the same name can behave differently across cores, so don’t copy settings based on labels alone.

Include DNS, LAN access and resume-from-sleep in your checks

TUN often involves capturing DNS traffic or using a dedicated resolution path. If IP addresses work but domain names don’t after enabling it, check DNS first. If names resolve but connections time out, check the outbound and server connectivity. Synthetic IP mechanisms require matching mapping and routing behavior; don’t treat those addresses as real destination addresses in permanent rules. Test internal company domains, LAN device names and services that rely on a specific resolver separately.

Your test checklist should include a regular website, an app that previously needed its own proxy setting, access to LAN devices and recovery after waking from sleep. After switching between Wi-Fi and wired networks, check whether the outbound interface changed. If only one network fails, look into its DNS, captive portal or management policies. Complete any required network sign-in before enabling traffic capture. Don’t keep restarting the core before the system has a working network configuration; that can make a network access issue look like a client problem.

On Android, also check background restrictions. Battery-saving settings may stop the app when the screen is off, causing intermittent disconnects. Allow the background operation it needs rather than disabling every restriction. In per-app settings, check whether the list includes or excludes the apps shown so you don’t select the opposite group. See VPN permissions, battery settings and per-app proxying for details. TUN is working as intended when you can explain what traffic it captures, verify common use cases and return to normal network access after turning it off.

Maintenance: keep a baseline and troubleshoot one layer at a time

Record a recoverable state before updating

Maintenance is more than clicking Update. Record the client type, core, subscription groups, active node and routing preset, then back up essential local settings. Subscription URLs and exported configurations may contain credentials, so store them somewhere private—not on a public drive or forum. Make sure you know how to restore a backup, what it contains and whether restoring it will overwrite current settings. You don’t want to discover during an outage that the backup is just an empty folder.

Updating the client, core, subscription and rule resources are separate tasks. A client update may change the interface and configuration management; a core update affects protocol implementation and runtime behavior; a subscription update refreshes provider-supplied nodes; a rule-resource update changes routing matches. Update one thing at a time, then check the logs and common destinations before moving on. If you update everything at once, it’s hard to tell whether to roll back the program, node or rules, and a temporary network issue may look like an update bug.

If you can’t connect, start at the entry point and narrow it down by layer

First check that your basic network works. Then confirm the client and core are running, check whether app traffic reaches the client, and finally inspect routing and the remote connection. No access logs? Check the entry point. Logs show a server connection timeout? Check the address, port and network path. A rejected handshake? Check authentication, transport and security settings. For time-based authentication or certificate errors, check the system clock too. Don’t treat every error as a reason to reinstall; the installation may have nothing to do with the failing layer.

If the same node works differently across apps, compare their system proxy, app-specific proxy, DNS and protocol requirements. If every node fails, check shared dependencies such as the local listener, core startup, network access and common DNS settings. If only one node fails, check that node’s server status and specific parameters. If changing networks fixes it, investigate differences in the network path—but don’t assume one test proves the cause. Record the conditions you can reproduce.

Interpret speed tests and log evidence

TCPing usually reflects only part of the connection to a target port. It doesn’t prove that the full proxy handshake or destination request will succeed. Real connection latency is closer to a request completed through the proxy, but it still depends on the test destination. Download speed depends on bandwidth, server load, destination site and local network, and it uses data. Don’t choose a node based on one number. First check whether real requests complete reliably, then compare repeated tests under the same conditions. Don’t mix results from different test methods.

When reading logs, focus on the time window for one failed attempt and find the first specific error, not the final summary message. Timeouts, connection refusals, DNS failures and authentication errors point to different stages. Before sharing logs, remove subscription URLs, user IDs, full server details and sensitive local paths. Keep only the error type and steps needed to locate the problem. A short, reproducible log is usually more useful than a full-screen screenshot.

After maintenance, check that settings are restored on exit, the system proxy is in the expected state and common apps still work. Keep a verified baseline, but don’t accumulate dead nodes and temporary rules indefinitely. See TCPing, real connection latency and download speed tests for how the tests differ, or visit Troubleshooting for common issues. Maintenance is complete when changes are documented, problems can be traced to a layer and recovery steps work—not when every toggle is switched on.

Advanced: go from getting connected to understanding the configuration

Stage 1: replace trial and error with repeatable tests

Advanced setup doesn’t mean writing a complete configuration file right away. Start by creating repeatable tests for common scenarios: fix one app, one destination and one entry point, record the node, routing and DNS settings, then observe the result of a request. Change one variable at a time and check the outcome before moving on. This builds knowledge you can apply to other nodes and networks instead of relying on a combination that happened to work once. If you can’t explain why it works, keep it as a note for now rather than presenting a guess as a general rule.

Learn what DNS affects, and distinguish system resolution, app-level resolution and core-level resolution. Check whether a domain has already become an IP address before traffic reaches the client, whether a rule needs the original domain and how DNS requests themselves are routed. Don’t start with a complex resolution chain; first identify what each layer is responsible for. For destinations with multiple address types, also check whether the system network can connect using them. A successful DNS lookup doesn’t guarantee that the address is reachable.

Stage 2: understand core differences in the context of real needs

Choose between Xray, V2Fly and sing-box based on the node protocol, transport combination, routing capabilities and client support. Before switching cores, list the features you must keep and confirm that the client can generate the required configuration correctly. Interface options may expose only part of a core’s capabilities, while custom settings may bypass some graphical controls. Don’t assume every setting will remain equivalent after a switch. Retest connections, DNS and routing instead of checking only whether the process starts.

Use a known working node to learn its parameters one at a time. The address and port locate the server; authentication details identify you; transport settings match the connection method; security settings establish the expected protection. The TLS server name isn’t an arbitrary note, and a REALITY public key isn’t a display field you can generate and replace yourself. Each value depends on the server configuration. Understanding these constraints helps you tell whether a problem comes from the client’s capabilities or from incomplete settings.

Stage 3: learn configuration structure and validation

When reading a full configuration, first identify the functional sections—logging, inbound, outbound, routing and DNS—then trace how their tags reference each other. Inbound defines what traffic is received; outbound defines how it’s connected or handled; routing maps match conditions to an outbound. A tag is just an internal reference name, not proof of what it does. Check the protocol and settings it actually points to. When working with another core, learn its structure again instead of reusing field names from a different format.

Before writing a custom configuration, copy a working one and test in an isolated environment. Check JSON syntax, where each field applies and how references connect, then validate its meaning with the relevant core. Valid syntax only means the file can be parsed; it doesn’t prove the core supports each field or that the server parameters are correct. Graphical clients may regenerate runtime configuration when they start, so don’t edit temporary files that will be overwritten. Use the custom configuration options the client provides and note which graphical settings remain active.

Build a minimal operations guide of your own

Document the stable workflow briefly: how to install and import configurations, which mode to use by default, which layer to check first, how to stop traffic capture and restore network access, and what to back up. Note the purpose of each exception rule and keep a rollback plan for every change. When moving to a new device, rebuild the basic connection first, restore subscription groups and common routes next, then enable TUN. Following the guide’s sequence helps avoid bringing hidden dependencies from the old environment into the new one all at once.

You should be able to answer four questions: where traffic enters, why it takes a particular outbound, where domain names are resolved and how to return to a baseline when something fails. When you can answer them and verify the setup with logs and real requests, you have a maintainable configuration. For more details, see the glossary, Troubleshooting and topic guides; you don’t need to enable every advanced feature at once. To revisit the shortest setup path, return to the quick start guide. Get a working baseline first, then add capabilities one layer at a time.