V2Ray Guide: From Core Concepts to Advanced Configuration

// FOUNDATION

Core Concepts: Clients, Cores, Nodes, and Subscriptions

Separate the interface layer from the execution layer first

What people call a “V2Ray client” is usually not a single program, but a combination of a graphical interface, proxy core, configuration files, and system network settings. v2rayN, v2rayNG, and v2flyNG display server lists, save subscriptions, switch proxy modes, and read logs; the core is what actually establishes connections, parses protocols, and handles traffic. v2rayN can manage compatible cores on desktop systems, v2rayNG primarily uses the Xray core as its execution layer, and v2flyNG targets the V2Fly core. Once this relationship is clear, troubleshooting no longer conflates an unchanged interface button, a failed core startup, and an unreachable remote server.

A graphical client generates a runtime configuration from the choices made in its interface, then starts local proxy ports. The browser or operating system sends requests to those local ports, and the core determines how to send them based on the protocol, transport, security parameters, and routing rules. As a result, using a node depends on at least four conditions: the server address must resolve, the port must accept a connection, the authentication parameters must match, and the transport and security settings must be compatible. A mismatch in any one group can appear as a connection timeout, handshake failure, or an inability to reach target sites after startup.

A node is not a subscription, and a subscription is not a proxy switch

A node is a set of specific connection parameters, usually including an address, port, user identifier, protocol, transport, and security settings. A subscription is an updateable data source that can return multiple nodes and group information at once. Adding a subscription to a client only tells the client where to retrieve configuration; you still need to update it, select an active server, and enable an appropriate proxy mode before traffic enters the core. If the server list is empty after a successful import, the subscription may not have been updated, its format may be unsupported by the current client, or the update request may not have completed.

Share links and subscription links should also be treated differently. A share link usually describes one node and is suitable for temporarily importing or moving a single configuration; a subscription link continuously maintains a group of servers and may add, remove, or modify nodes after an update. For format details, see subscription link formats explained. For long-term use, keep nodes in their subscription groups instead of copying them into unrelated local entries, or future updates will not correctly replace the old configurations.

Protocol, transport, and security parameters are three separate layers

Names such as VMess and VLESS primarily describe the connection protocol and authentication fields; TCP, WebSocket, and gRPC are transport-layer choices; TLS and REALITY handle secure handshakes or identity verification. Clients often place these fields in the same editing window, but they cannot be mixed arbitrarily. If the server uses VLESS, the client cannot simply change the dropdown to VMess; when the transport is WebSocket, the path, host field, and other parameters must also remain consistent. For the fundamentals, continue with the difference between VMess and VLESS.

// CLIENT AND INSTALL

Choose a client and install it for maintainability

Choose by platform, not by guessing from the name

For desktop platforms, v2rayN is the primary choice. It supports Windows, macOS, and Linux, making it suitable for users who manage multiple subscriptions, edit routing rules, inspect detailed logs, and use TUN. On Android, v2rayNG is the preferred option; if a subscription or existing configuration specifically targets the V2Fly core, v2flyNG is also suitable. The three clients do not have identical roles, so do not force a platform-incompatible solution merely to make every device look the same. All installation packages are listed on the downloads page, organized by processor architecture and package format.

Before choosing an installer, confirm two details: the operating system and the processor architecture. On Windows, x64 is common for desktop devices; macOS requires distinguishing Apple Silicon from Intel; most recent Android devices use arm64, while a universal package is suitable when the architecture is unknown; on Linux, in addition to x64 and arm64, choose deb or rpm according to the distribution. A mismatched architecture may prevent the program from starting, while an incompatible package format is usually rejected directly by the system package manager.

The installation location affects future maintenance

The Windows desktop edition and classic WPF edition use different interface technologies. The desktop edition suits users who want a similar workflow across desktop systems; the classic WPF edition suits Windows users already familiar with the traditional v2rayN workflow. If you download an archive, extract it to a fixed location with write permission instead of launching it from the archive preview. Configuration, logs, and temporary files must be writable, and frequently changing paths can also invalidate shortcuts and startup settings.

When opening an app for the first time on macOS, complete the confirmation through the system-approved launch flow, and make sure the package matches the processor. On Linux, after installing a deb or rpm package, launch it from the desktop menu and confirm that the tray icon or main window is visible. After installation on Android, enabling a connection for the first time triggers a system network-connection confirmation; this permission is required to create the local virtual network. If permission is denied, the node may be correct but the client cannot take over device traffic.

Make only three checks on first launch

First, confirm that the main window opens without persistent core startup errors; second, locate the log, subscription, and proxy-mode controls; third, verify that the system time and time zone are correct. Authentication or secure handshakes for some protocols depend on accurate time, and a large clock difference can make matching parameters appear correct while preventing a connection. During first-run setup, avoid changing DNS, routing, TUN, ports, and core options all at once; otherwise, it will be difficult to identify which setting caused a failure.

After installation, keep the default local listening settings initially. Common graphical clients manage HTTP, SOCKS, or mixed proxy ports; use the values shown in the client’s current settings page rather than copying a port from another device. If a port is already occupied, the logs usually report a listening failure or an address-in-use error. Close the conflicting program or change the local port in the client, then update browsers, terminals, or development tools that depend on it.

Windows: open Task Manager and confirm that the client process is running
macOS: open Activity Monitor and search for v2rayN
Linux: use the desktop system monitor, or run:
ss -lntp

// SUBSCRIPTION

Subscription import, groups, and update strategy

A complete import workflow has four actions

A reliable subscription workflow is: add the subscription URL, run an update, check the server list, and select an active server. Pasting a link into an editor and saving it does not mean that nodes have been added to the list. In v2rayN, create clearly named subscription groups before updating the relevant group; in v2rayNG and v2flyNG, save the address in subscription settings and refresh it manually. After the update, read the status message and confirm that recognizable configurations were received, rather than merely seeing that the request completed.

Keep the entire link when copying it. Chat tools and webpage layouts may insert spaces or line breaks, and parameters can be lost when only the visible portion is copied. If the imported list is empty, recopy the original address and verify the beginning, query parameters, and final characters. Do not “repair” a subscription by manually deleting apparently unnecessary encoded characters; they may be required data.

Groups control the update scope

Subscription groups are more than interface categories. They associate server entries with their source, allowing the client to know which old entries to replace during an update. Create a separate group for each subscription source and use a recognizable purpose or device scope in its name instead of naming everything “Default.” When multiple sources share one group, it becomes harder to identify where a node came from and easier to delete a still-used configuration while cleaning up expired entries.

Put manually added servers in a local configuration group or mark them clearly so subscription updates do not overwrite them. To modify a subscribed node temporarily, copy it to an independent entry first and edit the copy. Direct edits to a subscription-managed node may be restored from the remote content at the next update. Options such as “delete old servers on update” and “keep local changes” have different meanings; confirm whether the group contains manual entries that must be preserved before enabling them.

Set the update frequency according to how often things change

A subscription does not become better through more frequent updates. Update it during normal use when nodes change, the current server becomes unavailable, or the source announces a configuration change. An automated interval that is too short creates unnecessary requests and may lengthen startup preparation. A more reliable approach is to keep a reasonable automatic interval and trigger updates manually when needed. On mobile networks, avoid refreshing repeatedly while the connection is switching, or a temporary interruption may be mistaken for an invalid subscription.

Distinguish request failures from parsing failures. Request failures usually appear as timeouts, name-resolution errors, or refused connections; check the current network, system time, and whether the subscription URL is reachable. A parsing failure means content was retrieved but the client could not recognize its format; the response may be a login page, explanatory text, or an incompatible data structure. Repeatedly clicking Update will not change this result. Check the response type in the logs and verify that the client supports the subscription format.

Use speed-test results only for like-for-like comparisons

Latency tests, connectivity tests, and download tests in a client do not measure the same thing. A latency test usually reflects the round-trip time of a particular probe and cannot directly represent webpage loading or large-file transfers; a connectivity test checks whether a target is reachable; real-world performance is also affected by bandwidth, packet loss, the target site, and the current network. Rank nodes under the same network conditions, with the same test method and at roughly the same time. Do not compare numbers directly across different devices.

After selecting an active server, validate it against one or two stable targets instead of switching through many nodes. Frequent switching causes DNS caches, existing connections, and application retries to overlap, while making logs harder to read. If only a particular application fails with a node, record the proxy mode, target domain, and failure time, then locate the corresponding connection in the logs. For more interface details, see a quick tour of v2rayN interface sections.

Recommended subscription troubleshooting record:
1. Group name and update time
2. Update status or error text
3. Whether the number of server entries changed after the update
4. Current active server name
5. Proxy mode and test target used

// PROXY MODE

System proxy, per-app proxy, and traffic takeover scope

The local port is the entry point into the core

After startup, a client usually listens on one or more local proxy ports. An HTTP proxy suits browsers and desktop applications that support standard system proxy settings; a SOCKS proxy can be entered separately in software that supports the protocol; a mixed port accommodates multiple entry types on one port. The port itself does not determine which node handles the traffic; it only passes requests to the core. Node selection, DNS handling, and routing rules remain part of the runtime configuration.

When checking whether a proxy is working, confirm both that the core is listening and that the application actually points to that entry point. A client may show itself as running while applications that follow system settings bypass the core because the system proxy is disabled; a browser with its own proxy setting may continue using the local port even when the system proxy is off. Before troubleshooting, identify the active takeover method and avoid having system settings, browser extensions, and in-app proxies enabled simultaneously.

System proxy suits ordinary desktop applications

When the system proxy is enabled, the client changes the operating system’s proxy settings, and applications that support them send HTTP or HTTPS requests to the local port. This is simple to configure and works well for browsers, some communication software, and common desktop tools. Its limits are clear: programs that ignore system proxy settings, applications with custom network stacks, some command-line tools, and certain UDP traffic may bypass it.

Before closing the client, exit it normally or clear the system proxy first. If the program terminates unexpectedly, the system may retain settings that point to a local port no longer being monitored, causing the browser to suddenly lose network access. First check whether the system proxy still points to a loopback address, then disable the setting or restart the client. Repeatedly changing nodes cannot fix a missing local port.

Use in-app proxies for precise control

Development tools, terminal programs, and some browsers allow a proxy to be specified independently. The benefit is a clearly defined scope that does not affect other software; the drawback is that each program must maintain its own address and port. The proxy address is usually 127.0.0.1, and the port must match the current value in the client’s settings. If the application runs in a container, virtual machine, or on another device, the loopback address refers to its own network environment and does not directly represent the host.

For command-line verification, explicitly specify the local proxy to distinguish a proxy-chain problem from a program that did not read the system proxy. The command below uses an example site and only verifies whether an HTTP request can leave through the specified entry point. Replace the port with the actual local port shown by the client instead of copying a setting from another device.

curl --proxy http://127.0.0.1:local-port https://example.com/

If you do not want explanatory text in the command, read the port from the client’s settings page first, then run the command with the actual number. A normal webpage response indicates that the local HTTP proxy and active node are basically available; a message saying that the local address cannot be reached indicates that the core is not listening on that port or that the port is wrong; if the connection is established but remains unresponsive, continue by checking node, routing, and DNS logs.

// ROUTING

Traffic routing: match conditions, order, and the default outbound

Routing chooses the outbound; it does not repair a node

Traffic routing sends connections to a proxy, direct, or blocked outbound according to conditions such as domain, IP, port, and network type. It assumes that the underlying connection already works. If the active node cannot connect, adding more rules will not restore the link; if DNS returns an unexpected result, domain rules may also fail to match. Verify the node in a simple mode before configuring routing, then add rules gradually.

Common rule sets include fields such as domain, ip, port, network, and protocol. Domain rules are suited to site-based categories, IP rules to known address ranges, port rules to service types, and network rules to distinguishing TCP from UDP. The outboundTag in a rule points to an existing outbound label; if the spelling does not match, correct conditions still produce the wrong result.

Order rules from specific to general

Routing is usually evaluated in list order, with the first matching rule taking effect. Specific exceptions should therefore come before broader rules. For example, if a subdomain must use a proxy while its parent domain set should connect directly, put the subdomain rule first. Placing an “all domains” or “all IPs” fallback at the top prevents later rules from being considered. After editing, read the list from top to bottom and confirm that no rule consumes traffic intended for the next one.

The domain: prefix matches a specified domain and its subdomains, full: matches only the complete domain, keyword: matches by keyword, and regexp: uses a regular expression. For general configurations, prefer explicit domains or well-maintained geosite categories; use regular expressions only when ordinary rules cannot express the requirement. An overly broad regular expression creates unexpected matches and raises maintenance costs.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:service.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "udp",
        "port": "53",
        "outboundTag": "dns-out"
      }
    ]
  }
}

The fragment above shows the field structure and contains no server authentication information. The first rule sends two example domains to the proxy outbound; the second keeps private addresses direct so local devices are not routed through the proxy; the third sends UDP DNS requests to a dedicated outbound. In actual use, confirm that the runtime configuration contains the proxy, direct, and dns-out labels. If the client generates labels through its interface, use the generated results as the authority.

Domain strategy determines when IP rules participate

domainStrategy controls whether routing resolves an IP when it receives a domain request. With AsIs, routing primarily matches the original domain and does not resolve it solely for an IP rule; IPIfNonMatch resolves the address only if no domain rule matches, allowing IP rules to be checked; IPOnDemand resolves earlier when IP matching may be needed. Choose the strategy together with the DNS configuration, and do not interpret its name as a connection-speed setting.

When rules are primarily domain-based, first ensure that domain information remains available to the routing layer. If you rely heavily on geoip categories, confirm that DNS results are stable and that the resolution path is expected. Some applications connect directly to an IP and provide no domain for matching, so geosite or ordinary domain rules cannot apply; use IP rules or another identification method instead. Conversely, CDN addresses may change and are poor candidates for permanently hard-coded public IP rules.

Use logs to verify matches instead of guessing from results

When troubleshooting routing, record the target domain, access time, final outbound, and matching rule. If the client’s log level is too low, you may see only that a connection succeeded or failed, not the routing decision. Temporarily increase log detail during debugging, then restore the normal level to prevent rapid growth. If a target does not match the expected rule, check the rule order, domain syntax, outbound label, and DNS strategy in that order.

Add custom rules in batches. Start with a narrowly scoped domain rule and verify it, then add category and fallback rules; after each change, reload the configuration and confirm that no parsing errors appear in the logs. For complete syntax and priority examples, see how to write custom V2Ray routing rules. As the configuration grows, document each rule’s purpose and periodically remove exceptions that no longer serve a use.

// TUN MODE

TUN mode: full takeover, DNS, and exclusions

TUN addresses the scope of traffic takeover

TUN creates a virtual network interface that sends traffic from more applications that do not read system proxy settings into the client. It suits scenarios involving UDP, command-line programs, applications with independent network stacks, or unified routing rules. TUN is not a faster proxy mode and does not improve node quality; it changes the path by which traffic enters the core. The underlying node, subscription, and routing logic remain the same.

Before enabling TUN, verify the active node through the system proxy. If the connection already fails in system-proxy mode, enabling TUN directly only adds three variables: a virtual interface, DNS, and the routing table. The correct order is to confirm that the client and core work, verify the node connection, verify the basic rules, and enable TUN last. If something then fails, the cause is easier to narrow to permissions, the virtual interface, or takeover rules.

Permissions and system network components must be ready

Creating a virtual interface, modifying routes, and handling DNS usually require additional system permissions. On Windows, complete the permission confirmation shown by the client; on macOS, allow the relevant network component; on Linux, ensure that the current execution method can manage network interfaces. Android clients use the system-provided network connection interface to create a local tunnel and require confirmation on first activation. If the permission step is incomplete, the interface may briefly show “starting” and then report interface-creation failure in the logs.

When virtual networking software, enterprise network components, or security tools run at the same time, multiple programs may modify the routing table. Symptoms include inaccessible local devices, unexpected DNS paths, and broken connections after a network change. During troubleshooting, keep only one traffic-takeover tool active, confirm that TUN works alone, and restore other components one at a time. Do not enable default-route takeover in multiple programs simultaneously.

Design DNS together with routing policy

In TUN mode, DNS resolution determines not only the destination IP but also whether domain rules retain enough information to match. A client may offer DNS hijacking, virtual address mapping, remote DNS, and local DNS options. The goal is not to stack the most settings, but to ensure that queries follow the intended path, results return to the requesting application, and the routing layer preserves the correct domain association. If a webpage works by IP but fails by domain, check DNS first instead of immediately changing protocols.

Local hostnames, printers, and router administration domains usually depend on local DNS. If every query is sent to a remote resolver, these names may not resolve. Keep direct resolution for private addresses, local domains, and system-required lookups, then process other queries according to the rules. When using virtual addressing, ensure that the address range is managed only by the current client and does not overlap with a corporate network, container network, or existing virtual subnet.

Use exclusions to protect local resources

Common exclusions include loopback addresses, private network addresses, local devices, and system services that should not enter the proxy chain. Keep exclusions as precise as possible. Excluding an entire application is simple but sends all of its connections around routing; excluding an overly broad address range may also make intended targets connect directly. Before changing anything, identify what must be protected, then choose exclusions by application, address, or domain.

On mobile devices, also consider per-app proxying. In allow-list mode, apps you do not select do not enter the tunnel; in exclude-list mode, apps on the list connect directly. The semantics are opposite, so recheck them after migrating a configuration. On desktop, letting a virtual machine or container reach the host’s proxy also involves network boundaries and forwarding settings; do not simply expose the listening address on every interface.

Windows DNS cache flush:
ipconfig /flushdns

View routes on Linux:
ip route

View the default route on macOS:
route -n get default

// MAINTENANCE

Daily maintenance, reading logs, and isolating faults

Treat the program, configuration, and runtime state as separate maintenance targets

Client maintenance should not focus only on installer updates. Program files determine the interface and features; configuration data stores subscriptions, servers, routes, and preferences; runtime state includes the current node, system proxy, TUN, logs, and network interfaces. Upgrading the program will not automatically fix a broken subscription, and reimporting a subscription will not resolve a port conflict. Identify the layer involved before taking action to reduce unrelated changes.

Configuration backups should cover at least subscription URLs, custom routes, DNS settings, and manually added nodes. Store backups separately from installer packages and record the client they apply to. v2rayN, v2rayNG, and v2flyNG organize configuration differently, so do not overwrite their entire data directories across clients. During recovery, install the client for the matching platform, restore recognizable content through its supported import method, then check local paths, ports, and permissions.

Read logs by time and layer

Effective log analysis starts with the time of reproduction. Clear or mark old logs, perform one defined action—such as updating a subscription, starting the core, or visiting a target—and immediately inspect the new entries. Do not randomly search thousands of historical lines for “error”; an earlier error may already be resolved. Record the exact time of the action so interface behavior can be correlated with core output.

During startup, focus on configuration parsing, port listening, and the core process; during connection establishment, focus on DNS, routing outbound, handshakes, and timeouts; during operation, focus on network changes, interface shutdown, and repeated retries. A refused connection usually means the destination explicitly refused it or the local port does not exist; a timeout means no response arrived within the limit; a name-resolution failure points to DNS; a configuration parsing failure means the core never reached the connection stage. These errors require different responses.

An effective incident record should include:
- Operating system and client name
- Current takeover method: system proxy, in-app proxy, or TUN
- Time the problem occurred
- Active server and subscription group
- Target that reproduces the problem
- Log text from the corresponding time period
- Most recent settings change

Use a minimal configuration to isolate variables

When a complex configuration behaves unexpectedly, create a minimal path first: keep one known-working server, disable TUN, use the system proxy, and turn off custom routes and extra DNS rules. If the minimal path works, add DNS, routing, TUN, and application exclusions back one at a time, changing only one category of setting per step. This makes it clear which layer introduced the fault.

If the minimal path still fails, continue checking the local port, system time, current network, and server parameters. Switching to another network is an isolation technique for determining whether the issue is tied to the current access environment; it is not a substitute for log analysis. If the same configuration fails on different networks, return to the node parameters and core output. If only one network fails, check DNS, routing, network authentication pages, and how that network handles long-lived connections.

Make updates and rollbacks verifiable

Before updating the client, record the currently working state, including the active mode, group, and key custom settings. After updating, first verify that the program starts, the subscription can be read, and the node connects, then restore advanced features. If problems appear after an upgrade, distinguish configuration migration failure from changed runtime behavior. Directly overwriting the old directory may retain obsolete files, while clearing it entirely may lose subscriptions and rules. A safer approach is to keep a copy of the original directory and validate the update in a separate location.

When rolling back, do not revert the subscription content and client program at the same time, or you will not know which change restored functionality. Restore the program first and test it with the same configuration; if the issue remains, inspect configuration changes. Also remove expired servers, duplicate groups, and obsolete routing exceptions regularly. The leaner the configuration, the easier post-upgrade behavior is to verify.

// ADVANCED PATH

Advanced path: from a working configuration to an explainable one

Advanced configuration is not measured by the number of options

A stable configuration gives every setting a clear purpose and identifies the layer it affects. Importing a subscription and enabling a proxy are only the starting point; a maintainable system explains why traffic is proxied or sent directly, where DNS is resolved, and which applications TUN takes over. Do not turn on every advanced switch at once. Add one capability around one real need and leave a way to verify it.

Break the learning path into four layers. The first is client operation: subscriptions, active servers, logs, and the system proxy. The second is connection structure: protocols, transport, security parameters, and the relationship with the core. The third is traffic control: domain strategy, outbound labels, DNS, and TUN. The fourth is maintenance engineering: backing up configuration, isolating faults, evaluating changes, and rolling back safely. Do not rush to the next layer while the previous one remains unstable.

Create your own configuration baseline

A configuration baseline is a verified, working setup containing as little as possible. It should include one subscription group, one active server, the default local ports, basic system proxy settings, and only the necessary rules. Copy the baseline before each addition, and record the purpose and verification result of the change. If something breaks, return to the baseline immediately and determine whether the cause is the new setting or an external network change.

The baseline should also document platform differences. The interface locations, DNS implementations, and routing generation methods may differ across v2rayN, v2rayNG, and v2flyNG. Do not require every toggle to match across three devices. What should match is the intended behavior—such as direct access to the local network, proxying a specified service, or using the default outbound for unmatched traffic—not the order of options in an interface screenshot.

Turn rules into a decision table you can inspect

As the number of rules grows, write a decision table in plain text before converting it into client configuration. Each row should include at least the match target, condition, expected outbound, and verification target. For example: “private address — geoip:private — direct — open the router administration page” or “specified domain — domain rule — proxy — inspect the routing log.” This format exposes overlapping rules and makes it easier to reproduce the design in another client.

The default outbound must be explicit. Where traffic goes when no specific rule matches is the most important boundary in a routing design. If the proxy is the default outbound, identify which local resources must be direct first; if direct is the default, identify which targets must enter the proxy. Do not rely on memory of rule order; let the configuration structure express its priority.

Configuration change record example:

Goal: keep local network resources on a direct connection
Match: geoip:private
Outbound: direct
Position: after precise service rules and before the public-network fallback rule
Verification: access the local gateway and network devices
Rollback: disable the rule and reload the configuration

Learn DNS and network observation tools step by step

At the advanced stage, learn basic name-resolution and port-observation methods. nslookup or dig can show which resolver returned a domain result; ipconfig, ip route, and route can show interfaces and routes; ss can confirm local listening ports. These tools do not replace client logs; they verify from the operating-system side whether the state claimed by the client actually exists.

Interpret results in context. A domain resolving does not guarantee that the proxy connection succeeds, a listening port does not prove that the remote node works, and a TUN interface existing does not mean every application is covered. Each tool answers one question. Verify separate questions independently instead of ending the investigation after seeing one normal result.

Build a long-term maintenance loop

A complete loop consists of recording the current state, proposing one change, verifying it, and keeping or rolling it back. Follow this process for subscription updates, core-setting changes, new routes, and TUN activation. Record the final result after a successful change; if it fails, restore the baseline and retain the error log. As records accumulate, recurring problems shift from trial and error to reusable diagnostic paths.

Review client choices periodically as well. Use v2rayN as the primary desktop management tool, and choose between v2rayNG and v2flyNG on Android according to core and configuration requirements. For a side-by-side comparison, read v2rayN, v2rayNG, and v2flyNG compared. Base the choice on platform, configuration compatibility, and maintenance needs—not on the number of interface options.

After completing this guide, return to the quick-start guide and walk through the main path again, checking that you can explain the purpose of every step; when you need to replace or install a client, visit the downloads page and choose a package by platform; for a specific error, use Troubleshooting to search by symptom. The goal is not to preserve one configuration forever, but to master a workflow that can be verified, adjusted, and restored.