V2Ray Troubleshooting Guide

No internet access: find where the request stops

A “connected” status usually means the client started its core or opened a local service. It does not prove that a browser request reached its destination. Break the path into five stages: app, local inbound, routing, remote outbound, and destination service. Close other proxy apps, test the same website each time, and keep the v2rayN log panel open. Don’t start by changing protocols, DNS, TUN, and routing all at once. If the connection comes back, you won’t know which change fixed it.

Check the network and local listener

Clear the system proxy, then try a website that normally works without a proxy. If it still fails, check Wi-Fi, the gateway, captive portal sign-in, and system time; if needed, try another network on the same device. Reconnect the client after completing any portal login. Until the underlying connection works, proxy timeouts usually tell you little. If every browser loses access after you close the client, check whether the system still points to a local proxy port before blaming the remote server.

Next, select the target server in v2rayN and check for core startup errors. Open the relevant settings and verify the local listening address and port, then make sure the browser or system proxy uses that same port. Don’t assume a port shown in a screenshot is universal: values can differ by configuration and inbound type. If the logs report that a port is in use, close other clients and restart the core. If you change the port, update every app that uses it; otherwise, the local service may be running but receive no requests.

Use the logs to trace inbound traffic and outbound connections

Reload the page and check whether a new connection appears in the logs. If not, start with the app’s proxy settings: a browser extension may override the system proxy, the app may have its own proxy configuration, or the destination may be on the system bypass list. Logging depends on the selected log level, so an empty panel alone proves nothing. Confirm you’re viewing logs for the active core and temporarily use a level that records connections. Restore the previous level when you’re done to avoid excessive logging.

If a request reaches the core but is assigned to direct, check the routing mode in the status bar and the order of custom rules. Routing generally uses the first matching rule, so a broad direct rule near the top can override a later proxy rule. Temporarily switch to global proxy mode to see whether the issue is caused by split routing, then restore your original mode. “Global” changes the client’s routing choice; it does not automatically route every program on the system through the client. Apps that don’t use the local proxy may bypass it entirely.

Tell a general connection problem from a single-site issue

If several unrelated websites fail, continue with the server connection and DNS checks. If only one site is affected, try a new browser session and check whether the site is down, requires sign-in, or loads static assets from domains handled by different routes. A page that shows text while images keep loading may depend on several domains, so checking only the main address is not enough. Match requests to routing rules at the same time instead of repeatedly reloading the whole page.

Server timeouts: separate reachability from the protocol handshake

A timeout means a step did not finish within the allowed time. It does not, by itself, prove the server is down. A client’s test may check a TCP connection, access a test URL through the proxy, or measure something else; these tests don’t all measure the same thing. Check the test name and logs, then reproduce the issue with an actual browser request. If the test URL itself is unavailable, every server in the list may appear to fail. Don’t bulk-delete servers or overwrite a working subscription based on that result.

Check the address, port, and connection stage first

In the server editor, check that the address is complete and the port matches the value from your provider. Look for spaces or line breaks introduced when copying. If the address is a hostname, make sure the system can resolve it. If the log times out while connecting to the remote address, focus on network routing, server reachability, and the port. If the connection succeeds but TLS or authentication fails afterward, check the transport security and protocol settings instead. Treating these as the same error and changing settings at random usually takes longer.

Trying another network on the same device helps distinguish local network restrictions from a server issue. Trying a known-good configuration on the same network can show whether the problem is limited to one server. Keep the client, destination website, and routing mode unchanged during each comparison. On a corporate network, check for captive portal sign-in or a required gateway, and follow your organization’s network policies. Don’t open inbound firewall access just to pass a test: an outbound connection failure is not the same as exposing a local service.

TLS, transport, and REALITY settings

If a certificate error appears after the connection is established, check the device’s date, time, and time zone, then verify that the server name matches the configuration source. The TLS server name can differ from the connection address, but don’t substitute one for the other based on guesswork. An untrusted certificate chain, a name mismatch, and a handshake timeout require different fixes; use the full error message to choose the right path. Disabling certificate verification is not a standard fix: it can hide configuration errors and weaken identity checks. Correct the name, clock, or server certificate instead.

For WebSocket or gRPC, compare the transport type, path, Host, or service name field by field. Path capitalization, a leading slash, and characters in the service name can all affect matching. A reachable port does not mean these settings are correct. After importing a share link, check that every field was recognized. If the source format exceeds what the client supports, some fields may be missing. Don’t treat “transport type” as a performance setting you can switch at random; the client and server must use compatible settings.

With VLESS and REALITY, verify the server name, public key, short ID, and flow-control settings specified by the server. Each field has a different purpose and they are not interchangeable. Confirm that the selected core supports this combination. v2rayNG and v2flyNG use different core families, so don’t assume a share link will work the same way in both. The safest fix is to obtain a valid configuration and import it in full, rather than piecing together fields from unrelated guides.

Retry carefully and record the results

Rapidly reloading the core can overlap a brief network recovery, server-side connection limits, and an old process shutting down. After each change, wait for the core to finish starting, make one deliberate request, then check the first error from that time. If several errors appear in a row, fix the earliest one first; later connection closures may be a consequence. Record the network, server, destination, and stage where it stopped. Keeping a known-good configuration for rollback is more useful than a screenshot of a timeout message.

When contacting the configuration provider, say whether the remote connection failed or the error occurred after TLS, and include a log excerpt with sensitive details removed. Don’t send the full subscription URL or authentication fields. If other servers work reliably but this configuration always fails at the same handshake stage on different networks, further local routing changes are unlikely to help. Check the remote service status and configuration validity instead. For common field definitions, see the FAQ; a network timeout and protocol incompatibility are different problems.

Subscription errors: separate download failures from parsing errors

Updating a subscription involves two separate steps: fetching a response from the subscription URL, then parsing that response into server entries the client understands. When you see “update failed,” check the logs for connection, certificate, status-code, or parsing errors. A URL that opens in a browser may still not return subscription data; it could show a login page, verification screen, or expired-account notice. Don’t save the webpage and keep trying to import it, and don’t delete server entries that still work just because one fetch failed.

Check the subscription URL and fetch method

Open the subscription group settings and check that the URL is complete. Pay special attention to trailing parameters, spaces added during copying, and long links truncated by messaging apps. Subscription URLs often grant account access, so treat them as sensitive. If you’ve shared one in a screenshot or forum post, reset it through your provider if possible, then update the local group. A regular webpage, account dashboard, and subscription endpoint are different things; use the subscription URL explicitly provided by the source.

In v2rayN, you can try “Update subscription (without proxy)” or a proxied fetch, depending on your network; exact labels vary by version. If a direct fetch fails but a proxy works, use a known-good server to update. If the proxy is already down, relying on it to fetch the subscription can create a loop. Keep the existing group and retry using a method that can actually work. Captive portal sign-in or an unavailable local network can also make the subscription request return unexpected content.

Choose the right fix based on the response

If the logs show an HTTP status code, distinguish access denied, missing URL, rate limiting, and server errors. For an access issue, check whether the subscription has expired and whether its parameters are complete. If requests are being limited, stop clicking repeatedly and wait before retrying. For certificate errors, check the device clock and local trust settings. Don’t assume every status code means “the client is outdated,” and don’t bypass certificate verification just to fetch a subscription; that can hide the actual problem with the request path.

Share-link collections, Base64-encoded subscriptions, and native JSON configurations are different formats; a file extension alone doesn’t tell you which one you have. Base64 is an encoding, not proof that the content contains valid server data. A native core JSON file may not belong in a standard subscription field. Use the client’s appropriate import option and confirm it supports the data structure. For a single share link, try importing it from the clipboard first. This helps separate format issues from remote download problems.

Subscription group and active server after an update

After an update succeeds, check that the expected entries appear in the target group, then confirm the active server again. An update may rename entries or remove configurations that are no longer available, so the previously selected item may no longer work. A success message alone doesn’t mean the connection is back. Select an entry, connect, and visit a fixed website before investigating handshake settings. If several groups have similar names, confirm that you’re updating, viewing, and connecting to the same one.

Avoid setting an overly aggressive auto-update interval. Frequent fetches won’t fix a bad URL and may trigger rate limits. Scheduled updates can also coincide with wake-from-sleep or network changes. If manual updates work but automatic ones fail occasionally, compare the failure times with the device’s network state before rebuilding your configuration. Before changing group structure, export a recoverable copy using the client and store it somewhere protected.

For an overview of subscription formats and conversion limits, see V2Ray Subscription Formats Explained. Finish troubleshooting with a clear diagnosis: URL access, fetch method, response format, or configuration compatibility. That tells you whom to contact and what to change, and avoids starting over with a client reinstall the next time the same message appears.

Slow speeds: compare initial response, sustained transfers, and apps

“Slow” might mean a long wait before a page opens, images loading intermittently, unstable downloads, or video buffering. Each symptom can have a different bottleneck. First identify when the slowdown occurs, then test with the same device, network, destination, and server. Don’t use a server test as a substitute for real app performance. Latency measures the time for a round trip or test request; it doesn’t tell you sustained throughput or whether a website’s service is healthy.

Set up a fair comparison

Pause other high-bandwidth activity, check whether the device is in power-saving mode, and make sure the Wi-Fi signal is stable. Background sync, system updates, and other devices sharing the connection can make proxy speeds fluctuate. If useful, compare with a wired connection on the same network or test closer to the access point. Change one condition at a time. If you switch servers, networks, and browsers together, you won’t know which change made a difference.

If only the first page load is slow and later pages are fine, look at DNS queries, connection setup, and the TLS handshake. If the page appears quickly but large files transfer slowly, check available bandwidth, remote server load, destination rate limits, and packet loss. If only one video or download site is slow, compare it with another type of content. The destination may apply different policies based on exit location, account, or CDN node; changing a local port won’t necessarily help.

Check the actual route before drawing conclusions

Check whether slow requests use direct or proxy routing, especially for a site’s image, video, and API domains. The main page might use the proxy while static assets go direct, or vice versa, leaving some content stuck. If a custom rule is too broad, narrow its match and check its position. You can temporarily switch to global mode for comparison, but don’t treat it as a permanent fix: it changes the traffic path, not Wi-Fi interference, remote congestion, or delays at the destination.

When comparing two server configurations, keep everything else the same and record initial page load and sustained transfer separately. If one server is slow across multiple destinations while another works, focus on that route or remote resources. If every configuration is slow only for the same destination, investigate its DNS and service policies. Don’t keep restarting the core to chase a particular test score; dropped connections and rebuilt caches can skew the results and make performance seem worse.

Transport settings and network constraints

Don’t enable multiplexing by default or switch transports at random. Whether multiplexing helps depends on protocol support, connection patterns, and server settings; in some cases it can concentrate requests on one congested path. WebSocket, gRPC, and other transports must also match the server. Before trying an online “optimization,” check which core and version it applies to, back up the original configuration, and test one change at a time. Keep a setting only if you can explain and reproduce the benefit.

With TUN, if small pages work but large responses or specific apps repeatedly stall, investigate path MTU and how the network handles packets—but only after establishing reproducible conditions and checking logs or another network. Lowering the MTU is not a universal fix for slow speeds. First test the same destination through the regular system proxy. If that works, focus on TUN, the network adapter, and the network environment. Record the original value so you can restore it if the change doesn’t help.

After troubleshooting, keep a baseline for everyday use: a fixed test website, a known-good server configuration, and the normal routing mode. Compare future problems against it instead of repeating every suggested optimization. If performance varies noticeably by time of day, note when it happens and share that with your provider. Stable local settings make those observations useful. For split-routing rules, see How to Configure Split Routing in v2rayN.

DNS issues: separate app, core, and server name resolution

DNS problems can make a domain unreachable, delay the start of a connection, or produce different results in different apps. First identify which of three lookups is involved: how the operating system resolves domains, how the client core resolves destination domains, or how the remote server’s hostname is resolved. A browser may also use its own secure DNS and bypass the system resolver. Changing one DNS address won’t change every layer. Identify which component made the failing query first.

Use the error message to identify the DNS layer

If the logs say the remote server address could not be resolved, fix basic DNS for the server hostname first. The proxy connection cannot start without it, so remote DNS through that proxy cannot work either. If the remote connection is healthy but a destination domain fails, check which resolver handles the destination query and which route it uses. Don’t replace the server address with an arbitrary IP and call the issue fixed. Some configurations rely on the hostname, certificate, or a dynamic address; an IP substitution may only mask the problem and complicate future maintenance.

A system lookup tool shows the system’s current DNS result; it doesn’t prove that the browser or core uses the same resolver. Use the following command in a terminal to compare the system lookup; the test hostname is a public example and contains no account information. Even if the command succeeds, check the app logs to confirm the real connection path. If the system lookup fails but the browser works, the browser may use its own resolver or cache. If the system lookup succeeds but the client fails, check the core’s DNS settings and its outbound dependencies.

nslookup example.com

How routing strategy affects DNS results

In Xray routing, domainStrategy determines when the router attempts to resolve a domain to an IP address during rule matching. AsIs does not resolve domains for routing matches. IPIfNonMatch tries IP matching when no domain rule matches. IPOnDemand attempts resolution when a rule needs an IP address. This is a routing-layer strategy, not a list of DNS servers. Don’t confuse it with a similarly named field in an outbound configuration. Confirm the configuration layer before making changes.

The snippet below illustrates a routing object. Merge it into an existing configuration that includes the required outbounds; it is not a complete client configuration and should not be started on its own. If the client has a graphical routing editor, use that first. The core checks rules in order: the example handles specific domains before private IP addresses. Use outbound tags that exist in your configuration. Whether a domain reaches the core as a domain also depends on the app’s proxy protocol and DNS behavior.

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

Caches, encrypted DNS, and circular dependencies

After a DNS change, the operating system, browser, or app may still use an old result, and existing connections won’t be rebuilt automatically. Close affected pages and reconnect; if needed, clear caches using the method provided by your system, then check a new request. Don’t enable several encrypted DNS features before you know which route handles the query. Combining browser, client-side remote, and system DNS can make results harder to explain and hide the behavior of domain-based routing rules.

If a DNS service must be reached through the proxy, watch for a circular dependency: the proxy server’s hostname must resolve before the proxy can connect, but without that connection the client cannot reach a DNS service that depends on the proxy. Use a startup-time resolution path supported by the client and check how the DNS service’s own hostname is handled. Don’t send all DNS traffic to an outbound that isn’t available yet, or copy the same DNS configuration between different core families without checking compatibility.

To verify recovery, test the original failing domain and a normal site of another type, then confirm that routing still behaves as expected. Restoring access while sending all traffic through a different exit does not complete a split-routing diagnosis. If the logs report missing geosite or geoip data, investigate rule data loading in Startup and crashes rather than continuing to change resolvers. For rule prefixes and match order, see Xray Custom Routing Rule Syntax.

System proxy not working: check whether the app uses the local inbound

The system proxy and routing mode are separate settings. The system proxy tells apps that support it where to send requests; routing mode chooses an outbound for requests that reach the core. Setting v2rayN to “Global” does not capture all system traffic. A browser may follow the system proxy, while command-line tools, games, and other apps may have their own settings. Check how the affected app handles proxies before deciding whether to configure it directly or use TUN.

Understand the three status-bar options

“Set system proxy” writes the proxy settings the client needs. “Clear system proxy” removes those settings. “Do not change system proxy” leaves the current state alone; it does not turn the proxy off. If incorrect settings were already in place, choosing “Do not change” may preserve the bad route. Before testing, note the existing settings so you don’t overwrite ones required by a work network or another app, then select the option you need for this test.

Check the proxy address and port in your system’s network settings; don’t rely only on the client’s status indicator. If the system values differ from what the client shows, another proxy app, browser extension, automatic configuration script, or management policy may be changing them. Run only one proxy client at a time, temporarily disable browser extensions that control proxy settings, and test again. On managed devices, proxy policies may be set by your organization. If settings revert automatically, check the policy instead of repeatedly overriding it.

Manual proxy settings and environment variables

For apps that support manual proxies, temporarily enter the local address and port provided by the client to compare behavior. Use an HTTP inbound with an HTTP proxy option the app supports; use a SOCKS inbound with its SOCKS setting. Don’t swap them just because the ports look similar. If the listener is bound to the local machine, other devices can’t connect to it directly. You don’t need to expose LAN access to troubleshoot a local issue, and binding to every network interface is not a standard fix.

Command-line programs may read HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY environment variables—or ignore them entirely. A terminal that was already open may not pick up system proxy changes made in the graphical interface. If only command-line tools fail, check their proxy documentation and current environment variables. If only a browser fails, check its extensions, profile, and app-specific proxy settings. Don’t infer the whole system’s state from one app; differences between apps help pinpoint the inbound path.

TUN and restoring connectivity after exit

TUN is a separate way to route traffic. It may involve a virtual network adapter, routing table, permissions, and DNS interception; it is not another name for the system proxy. If the system proxy works, establish a baseline with that path before troubleshooting TUN. Enabling both without understanding their settings can send some traffic the wrong way or create a loop. Grant only the permissions needed. Running the entire client with elevated privileges all the time is not a reliable fix.

If the network stops working as soon as you exit the client, check whether the system proxy still points to a local port that is no longer listening. Reopen the client, select “Clear system proxy,” and confirm the change in system network settings. Also check for manual proxy settings in individual apps. A forced shutdown, system crash, or software conflict can interrupt cleanup on exit. Remove stale settings before considering a reinstall; reinstalling may not clear proxy settings stored separately by the system.

To verify the fix, make a new request in the same browser and confirm it appears in the logs, then check that its outbound matches the routing rules. If traffic reaches the core but uses the wrong outbound, revisit split routing instead of changing the system proxy again. Desktop environments differ in how they handle proxy settings, and Linux apps in particular may use their own network stacks. Configure the app explicitly if needed. For a repeatable setup, see the getting started guide.

Startup and crashes: check the interface, core, and configuration resources separately

A client window that won’t open, a core that fails to start after the window opens, and a process that exits after running for a while are three different problems. Note when the failure occurs: does the program close immediately on launch, show an error after you select a server, or fail only after a subscription or rules update? v2rayN’s interface and proxy core have separate roles. A visible interface does not prove the core is running, and a core exit does not necessarily mean the whole client crashed. Check the app message, core logs, and system error records separately.

Installer, architecture, and runtime requirements

First check that the download matches your operating system and processor architecture. v2rayN is the recommended desktop client. The Windows desktop and classic WPF versions differ in interface and runtime requirements; for macOS and Linux, choose the download that matches your chip and distribution. To get the program again, check the platform details on the client download page. Don’t rely on the file icon to identify its architecture or replace a single executable from an old folder; that can leave the program and its resources out of sync.

If the program needs a runtime, use the installer prompt and system error details to identify the required component instead of downloading something with a similar name. Check that the installation location is writable and executable, isn’t restricted, and hasn’t been blocked by security software. Review the block log before deciding what to do; don’t disable all protection. On Linux, also check file permissions and the desktop launcher. On macOS, follow the system’s security and permission prompts to verify the app and allow it to run.

Use the first error to diagnose core startup failures

If the core log reports a listener failure, check the address and whether the port is already in use. If it reports a configuration parse error, check JSON syntax, field placement, and compatibility with the selected core. JSON doesn’t allow trailing commas, and each field must have the right type: numbers, strings, and booleans are not interchangeable. If a graphical client generated the config, correct the source setting in the interface first. Manually editing a temporary generated file may be overwritten on the next reload, making the same problem return.

listen tcp 127.0.0.1:1080: bind: address already in use

The message above shows a typical port-in-use error. The port is an example, not the client’s default. Once you know what is using it, close the conflicting program or change the listening port in the client and update the app’s proxy settings to match. Don’t terminate system processes you don’t recognize. If an old core process hasn’t exited, close the client normally, wait, and restart it. If stale processes keep appearing, check for security software interference, permissions, and exit logs instead of repeatedly restarting.

Rule data, core compatibility, and configuration rollback

For geosite or geoip errors, check whether the data files exist and are readable, and whether the referenced collection is included in the current data. A misspelled rule name and a missing file are different problems; updating the data won’t fix an invalid collection name. Custom rules copied from another core may also use fields this core doesn’t recognize. Revert the most recently added rule and check whether the core starts, then restore rules one at a time. This is safer and preserves more working settings than deleting all routing rules.

When switching between Xray and V2Fly core families, recheck protocol, transport, and extension-field compatibility. They’re related ecosystems, but not every configuration works with both. If the error occurs with only one core, establish a baseline using a configuration that core explicitly supports, then investigate the differences. Don’t force a core replacement by renaming files or leave core-specific fields in a configuration for another core. Use the client’s core selector with its matching configuration workflow.

If the interface crashes while loading user data, exit the program, back up the client data directory, and create a separate clean configuration using a method supported by the client. Don’t delete the original directory right away; it may contain groups, routes, and subscription data. If the clean setup works, restore settings in batches to identify damaged or incompatible items. If it still fails, check runtime requirements, permissions, and system logs. For more on reading errors, see How to Diagnose v2rayN Core Startup Failures.

Android troubleshooting: VPN permission, per-app routing, and background limits

On Android, v2rayNG and v2flyNG usually route app traffic through the system VPN interface, so their troubleshooting path differs from the desktop system proxy. A VPN icon in the status bar only shows that the system has a VPN connection state; it doesn’t prove that the remote handshake or destination access works. Select an active configuration in the client, connect, check the logs, and test a fixed website in a browser. The two clients use different core families, so check compatibility for specific protocol and transport combinations rather than assuming they work alike because their interfaces look similar.

System authorization and VPN conflicts

The first connection requires system VPN authorization. If you deny it or a system policy blocks it, local traffic won’t reach the client as expected. Check whether another app using the VPN interface is running, such as a network filter or work profile tool. These apps may compete for the same connection slot, so starting one can affect the other. Stop the conflicting app, reconnect, and check the system prompt. On organization-managed devices, confirm which VPN apps and settings the device policy allows.

Always-on VPN and blocking connections without a VPN change what happens when the connection drops. If the client isn’t running or connected while the system still requires all traffic to use a VPN, the device may lose all network access. Before changing these options, understand their purpose and note the original state. Don’t mistake a lockdown rule for a Wi-Fi problem or reset all network settings without checking. First bring the client and system policy back into a consistent state.

Per-app rules and network changes

If only one app can’t connect, check whether per-app proxying is enabled and whether the mode is “proxy selected apps” or “bypass selected apps.” These modes do the opposite, so selecting the same app can have opposite results. After changing the list, reconnect if the interface requires it so the new rules take effect. System apps, work-profile apps, and regular installed apps may be treated as separate entries. Matching names alone doesn’t guarantee you selected the right app.

If Wi-Fi works but mobile data doesn’t, disconnect, wait until the target network is stable, then reconnect. Check mobile data permission, data limits, and captive portal status. A network switch changes the address, routes, and DNS environment, so existing connections may not survive. Use the same approach in reverse, keeping the server and test website unchanged. If DNS or remote connections fail only on one network, continue with the relevant section. Don’t clear the subscription: its entries don’t automatically become invalid when you change networks.

Disconnects when the screen is locked

If the connection works in the foreground but drops when the screen locks, check battery optimization, background activity, and automatic cleanup settings. Options vary by device, so look in the client’s system app details and adjust only the settings needed for a persistent connection. Don’t change every power-saving setting at once, or you won’t know which one caused the restriction. Afterward, lock the screen, wait, then check the client process, VPN status, and log timestamps to distinguish a killed process, a sleeping network, and a remote disconnect.

Swiping the app away from recent tasks, using a one-tap cleaner, or enabling extreme power saving can affect background services. If the system still shows a VPN icon but the app logs have stopped updating, reopen the client and check its status. If needed, stop it normally and reconnect. A notification alone doesn’t prove the connection is healthy. Background operation also uses device resources; after recovery, check battery use, network activity, and stability. If high resource use coincides with repeated reconnects, fix the network or configuration problem causing them.

Install, update, and verify recovery

Choose a package for your device architecture from the Android download page. If you’re unsure of the architecture, check the device information and download-page notes. An installation failure may be due to an incompatible architecture, unmet system requirements, insufficient storage, or a different source for the existing installation. Don’t uninstall just to try another package; save your configuration and subscription data first. Switching between v2rayNG and v2flyNG is more than changing the app shell, so check that the core in the new client supports your configuration.

For the final check, test browsing in the foreground, after locking and waking the screen, and after one network change. Confirm each request reaches the client and follows the expected route. With per-app routing, test one app that should use the proxy and one that should bypass it. Record the minimum settings needed for recovery and leave other system options unchanged. If you still need help, provide the device OS, client name, network type, and an error excerpt with sensitive details removed. Return to the getting started guide for basic setup, or see the FAQ for individual settings questions.