Technical reference for protocols and routes

Connection model: a protocol is not the entire route

Before comparing connection performance, separate the key terms. A protocol defines how the client and server identify each other, encapsulate requests and transfer data. The transport layer handles delivery; route topology determines which networks the data crosses; and the exit is the source address seen by the destination website. These components affect one another, but they are not interchangeable. Changing protocols does not change the exit region or necessarily shorten the international route. Treating all of them as a single measure of “node quality” makes troubleshooting harder.

From Click to Content

When you open a webpage, the app identifies the destination, establishes a connection, completes any required authentication and encryption negotiation, then exchanges the actual content. DNS resolution, the proxy connection, the remote request and page resource loading can all add wait time. A connected status in the client only confirms that one part of the connection succeeded; it does not mean the app's entire process is complete. So “connected but slow” is no contradiction: the delay may be in name resolution, access from the exit, or the app's response.

A first visit and continued use also create different workloads. A cold connection has to establish new state, while a reused connection can skip some setup. Webpages make many short requests and can be sensitive to handshakes and DNS lookups; file transfers occupy the connection for longer and depend more on steady throughput; streaming responses need an uninterrupted connection and rely on data continuing to arrive. Before comparing protocols, identify the specific wait you want to address instead of relying on a general impression of speed.

Break Performance Down into Observable Signs

Latency is the time for a round trip, jitter is how much that time varies, and throughput is the amount of data actually delivered over time. Low latency does not guarantee fast large-file transfers, and high throughput does not guarantee consistently responsive interactions. Voice calls and remote control are especially sensitive to jitter; video can buffer and tolerate some short-lived variation. The goal is not to minimize every metric at once, but to identify the kind of degradation the current app can least tolerate.

Connection setup time also depends on whether the client keeps sessions, whether the server allows reuse, and whether certificate checks succeed. The same protocol can perform differently across implementations and configurations. Device OS, network provider and access method also affect results. When you see a claim that a protocol “connects faster,” ask whether the test used the same entry point, exit and app request. If those conditions differ, the protocol alone cannot account for the observed difference.

Assess Security and Service Availability Separately

Encryption protects data in transit across a specific boundary; it does not fix account permissions, regional service requirements or app failures. VPNGas uses “quantum encryption” as a key trust message. That should not be taken as proof that a particular protocol has been audited or that a specific algorithm is necessarily enabled in the client. For details about cryptographic mechanisms, consult the implementation documentation. For access issues, check the exit, account rules and actual response rather than using a security label to explain every connection problem.

A subscription is a way to deliver configuration, not a separate network protocol. It provides route addresses, credentials and rules to the client, which applies them according to its capabilities. Updating a subscription can sync configuration changes, but it cannot replace correct system proxy settings. If a route appears in the user panel but not in the client, check the import and update. If the client lists the route but the app is not using the proxy, check which traffic is being routed. Resolve configuration issues before investigating transport efficiency; it is usually quicker.

Shadowsocks and VMess: encapsulation and compatibility trade-offs

Shadowsocks is designed to provide a relatively direct encrypted proxy channel. The client receives an app request, packages the destination details and data as specified, then forwards them through the server. It does not handle the app's account permissions or bundle every network issue into the protocol layer. Understanding this boundary matters: a compact protocol design can mean fewer configuration concepts, but actual resource use still depends on the encryption implementation, number of connections, traffic routing and device capabilities. It does not automatically mean “always more battery-efficient.”

Shadowsocks: Check Compatibility First

With Shadowsocks, the client and server need compatible encryption methods and parameters. Implementations with similar names may not accept exactly the same configuration, and plugins or additional transport layers can change the actual route. If a connection fails to establish, first check that the subscription is complete, the client recognizes the relevant fields and the system clock is correct. Repeatedly changing the local port is unlikely to help. Successful import only means the configuration syntax was accepted; it does not confirm that the remote end supports it.

Whether it suits a particular use case depends on the available routes. For everyday browsing, routine file transfers and consistent management across devices, mature client support may matter more than the protocol name. If the current route is stable, a more complex encapsulation may add little and could introduce extra handshakes or compatibility issues. Conversely, if an app depends on datagram forwarding, confirm that the client, server and entire route support it; ordinary webpage access does not prove that they do.

VMess: Separate Protocol Features from Transport

VMess has its own authentication and data encapsulation mechanisms and is often combined with different transport methods. A VMess configuration may also include encrypted connections, a domain, a path and other transport options. Make those conditions explicit when comparing setups; otherwise, the effect of the outer transport can be mistaken for a VMess feature. Correct credentials will not help if the outer parameters differ. Checking only the user ID is not enough to verify the full connection setup.

The system clock is another basic item worth checking when troubleshooting compatibility. Some authentication and security mechanisms rely on a reasonable time setting, so an incorrect device clock can make a valid configuration appear to fail authentication. Restore automatic time synchronization, then reconnect. Do not disable security checks to clear an error, and do not treat a temporary recovery as proof that the configuration is correct. Error messages, client logs and repeatable access results should be considered together.

Don't Treat Multiplexing as a Guaranteed Speed Boost

Multiplexing lets multiple app requests share an underlying connection, reducing the overhead of establishing each one separately. Sharing also means requests can affect one another: if the underlying channel stalls, other requests may have to wait. Short webpage requests may benefit, while mixing sustained downloads with interactive traffic may not. Test the client's default multiplexing settings first. Only adjust them if you observe a specific issue and the server allows it; don't change settings just because they sound more advanced.

Neither protocol has a universal speed ranking across devices. Keep the same destination and access network, then compare cold starts, continued browsing and recovery from background activity. Also check device heat and error logs. If the protocols use different exits, the only valid conclusion is that “these route combinations currently perform differently,” not that one protocol is inherently better. A stable, maintainable setup is usually more suitable for daily use than one that occasionally reaches a higher peak but requires constant manual adjustment.

Trojan and VLESS: encryption boundaries and connection setup

A common Trojan deployment uses TLS to establish a secure transport, then handles proxy requests and authentication within it. TLS protects the connection between the client and the relevant server and uses certificates to verify the connection's destination. It is not a layer to ignore. The domain, certificate validity and server configuration form a chain of trust; any mismatch should be addressed. If you encounter a certificate error, check the configuration and system state rather than skipping verification.

Trojan: Certificates and Authentication Have Separate Roles

A valid certificate does not mean proxy authentication has succeeded, and valid proxy credentials cannot compensate for a certificate that does not match the destination. Separating these checks helps narrow down the issue. If the log shows that the encryption handshake failed, first check the system clock, the server name in the subscription and client support. If the secure connection is established but a request is rejected, check the credentials and server status. Calling all these errors “a dead node” throws away useful clues.

Connection setup cost is not determined simply by counting protocol layers. Longer network round-trip times make interactive negotiation more noticeable; session resumption and connection persistence also affect the difference between a first visit and subsequent visits. On devices that frequently move between foreground and background, reconnecting may matter more to the user than a long download. Test opening the app, returning after a brief pause and resuming after a network change separately instead of using one file transfer to represent every situation.

VLESS: Lightweight Encapsulation Doesn't Provide Every Security Feature

VLESS delegates some capabilities to external transport and security layers. Its configuration may look simple, but that does not mean VLESS itself provides every form of encryption protection. To evaluate the complete setup, check which security mechanism the outer layer uses, whether the client verifies the remote identity and which transport options are enabled. The protocol name is only one part of the combination. When reading configuration details, distinguish proxy protocol fields from transport and security fields; they serve different purposes.

Routes labeled VLESS may have different compatibility requirements depending on their outer-layer configuration. A client that supports the protocol name may not support every combination used by the server. If import succeeds but fields are unrecognized, features are ignored or the connection fails, check the client's capability documentation and get a compatible configuration from the user panel. Do not piece together unfamiliar settings found online; they may depend on a different server setup and make the problem harder to reproduce.

Connection Reuse and Early Data Have Limits

Session resumption can avoid some repeated negotiation, but it depends on both implementations, session state and server policy. Some early-data mechanisms also involve replay risks, so not every operation is safe to repeat. Reading public content is not the same as submitting an order. Use configurations provided by the service. Developers evaluating connection behavior should confirm that the app supports idempotent operations rather than changing security-related settings just to reduce setup time.

Choosing Trojan or VLESS does not mean an app will use the same exit. The exit region, IP reputation, destination service policies and account status may affect the outcome more than encapsulation differences. If a webpage loads but a particular feature does not, first check the destination service's access requirements. If every app fails during connection setup through the same exit, investigate the transport and security layers. This distinction helps avoid trying to fix account permissions with certificate changes or misdiagnosing a configuration error as a regional restriction.

For easier maintenance, keep track of where configurations came from. Record the client, route label and stage at which an error occurred; do not post a complete configuration containing credentials in a public forum. If behavior changes after a subscription update, first confirm that route settings have synced, then retest under the same conditions. For everyday use, valid security checks, full client support and explainable errors are more valuable than shaving off a few bytes of encapsulation.

Hysteria2 and TUIC: performance on unstable networks and transport strategies

Hysteria2 and TUIC are commonly discussed as QUIC-based proxy options. QUIC uses datagrams to carry connections and handles encryption, reliable delivery and congestion control within the protocol. The point is not that “datagrams eliminate packet loss”; rather, another set of mechanisms manages loss, recovery and the relationship between streams. Whether the route allows this traffic, how the device handles datagrams and which implementation the server uses all affect whether it works smoothly.

What Independent Streams Can Improve

With a shared reliable byte stream, a missing piece of data can hold up later content. QUIC can reduce this kind of cross-stream waiting by delivering independent streams separately, but missing data within a stream still needs to be recovered, and the connection still shares route capacity and congestion. It cannot turn a congested link into unlimited bandwidth. Differences may show up with parallel webpage requests, while a single sustained transfer still depends on packet loss, round-trip time and congestion control working together.

Performance discussions around Hysteria2 often involve bandwidth-related settings and congestion strategies. Bigger settings are not always better: going beyond the actual access capacity can cause extra queuing, packet loss and resource contention. If the server provides recommended settings, start with those and observe how your apps perform. Do not enter a plan's data allowance as a bandwidth value; they mean different things. The former is the total amount of data available, while the latter describes a transfer rate or related control target.

TUIC: Capabilities Depend on the Complete Implementation

TUIC also uses QUIC connection and stream capabilities to carry proxy traffic. Performance depends on connection reuse, datagram handling, client scheduling and server settings. Being based on QUIC does not make different projects' configuration formats interchangeable. Credentials, certificate requirements and forwarding methods must all match. If a configuration imports successfully but the connection fails, check the supported-features list and logs rather than copying setting names from another protocol.

A network change can be supported by the underlying connection without every app recovering seamlessly. The implementation may not enable migration, and a change in route address may trigger restrictions from an intermediary or the server. The app itself may also time out while waiting. Check whether an existing task continues after the switch, whether the app reconnects automatically and whether it repeats an operation. The client's toggle merely remaining enabled is not enough to confirm successful recovery.

Check Compatibility and Battery Use Together

Some public access networks handle datagram traffic differently, so webpage proxying may work on a device while QUIC-based options struggle to connect. If the service offers another transport option, try it to check whether the issue is route compatibility. This does not prove a protocol is broken, and repeatedly increasing the sending rate is not a useful way to test it. If the local network requires an access login, complete that first, then start the proxy connection.

Encryption and datagram handling can create different processor workloads on mobile devices, depending on the system network stack, client implementation and transport task. Frequent recovery and continuous sending under weak signal can also use more radio and processor resources. When evaluating an option, look beyond downloads: check whether the connection stays active with the screen off, device temperature and background recovery. A setup that reaches a higher peak but keeps the device hot may not suit mobile work that needs long standby times.

Treat these protocols as alternatives with specific use cases, not universal upgrade buttons. First confirm that the service offers the relevant configuration, then compare under the same access conditions and workload. Check successful connection, sustained delivery and recovery before considering throughput. There is no need to migrate a stable task just because a newer protocol is available. If a route frequently fluctuates, check the route topology too instead of repeatedly changing protocols.

Direct, relay and dedicated routes: how the path affects performance

Route topology describes how data travels from the access network to the exit. A direct route usually means the client connects straight to the relevant remote entry point. A relayed route adds a forwarding node, sending traffic through an intermediate location before it reaches the exit. A dedicated route refers to a particular segment using dedicated transport capacity. These are not fixed rankings by latency. Geography, carrier peering, actual routing and shared capacity all affect performance, so a route label alone cannot predict how it will perform at peak times.

Direct Routes: Fewer Steps, Still Shaped by Network Routing

A direct route may look simple, but the client cannot control how the internet provider sends data to the remote end. Different access networks may use different peering points to reach the same exit region. Even devices in the same location may take different routes over wired, Wi-Fi or mobile access. A direct route can be efficient, or it can fluctuate because of detours or congested peering. A simpler protocol cannot remove delays caused by physical distance and actual routing.

When evaluating a direct route, distinguish whether the entry point is reachable from whether the destination service responds. If the connection to the entry point is slow, focus on the access-to-entry segment. If it connects quickly but content delivery stalls, check the exit-to-destination path, shared capacity and app workload. Geographic proximity does not guarantee a short network route. Choose a region based on the destination service's requirements, not just map distance; this is especially relevant to streaming catalogs and region-specific services.

Relayed Routes: An Extra Hop Can Improve Peering

A relay can reorganize a route by adding a forwarding step. The client first connects to an entry point better suited to local access, then an intermediate network carries the traffic to the exit. If the intermediate segment has better peering, overall performance may improve. If the relay device or link is congested, the extra step can become a bottleneck. Relayed routes are not necessarily slower or inherently more stable; it depends on which part of the route they replace and what the new node does.

Entry and exit locations are different things. The relay entry location is not necessarily the region a destination website identifies; apps typically see the final exit. If you need content from a specific region, check the route's exit label rather than inferring it from the entry name. The service may also change the underlying route during maintenance, so past experience is no substitute for current route information. See available regions and route labels on the VPNGas server page.

Dedicated Routes: Assess the Covered Segment, Not the Whole Path

An IEPL dedicated line generally refers to dedicated transport capacity between specific locations. Its role is limited to the segments it covers. The home network, wireless access and device-to-entry connection, as well as the route from the exit to the destination platform, may still use other networks. Even with a stable middle segment, weak signal at the device, exit congestion or a destination outage can affect the entire task. Assuming that a dedicated line means the entire connection is exclusive is a common but inaccurate conclusion.

A route label does not replace testing with the actual app. The same exit may reach different content delivery locations for different platforms; even one platform may use different domains for its website, login and video resources. Loading the homepage does not guarantee that the entire playback route works. Note the specific action that fails and retry through the same exit. Avoid changing both region and protocol at once, or you will not know which change made a difference.

A useful route comparison considers both path quality and maintenance effort. Keeping a primary and backup setup for regular tasks makes problems easier to reproduce than chasing an unfamiliar entry point that is occasionally faster. VPNGas covers 90+ countries / 150+ routes, providing a range of options; it does not mean every route works equally well for every destination. Choose based on your current access network, destination requirements and sustained performance.

Packet loss and peak hours: distinguish congestion from local faults

Data that does not arrive on time may be lost or simply delayed in a queue. Network equipment, wireless access and apps can all introduce waiting. When the sending rate stays above a segment's processing capacity, queues grow and interactive latency rises; once capacity is exhausted, packets may also be dropped. What feels like a “frozen network” often involves queuing, recovery and app timeouts at once. A single connectivity test cannot identify the cause.

Wireless Packet Loss and Route Congestion Are Different

Weak Wi-Fi signal, nearby interference or a busy access point can cause retransmissions locally. Even if the international route is fine, all tasks using that access network may be affected. Try a more stable access environment on the same device, then retest using the original route. If the problem changes significantly, start with local Wi-Fi coverage and competing traffic. Changing remote routes without checking local access can make a temporary improvement look like a protocol optimization.

Route congestion often shows up as lower throughput at busy times, increased wait during interactions, or other tasks slowing down when a download starts. This relates to shared link capacity and queue management. A protocol's congestion control adjusts sending behavior but cannot know the priority you assign to each task. A sustained transfer can fill the access link and make short requests wait too. Pause unnecessary syncing or downloads and see whether interactions improve; that is often more useful than immediately changing encryption methods.

What Connectivity Checks, Speed Tests and App Tests Tell You

A connectivity check shows that a test destination responded; it does not prove that the app follows the same route. A speed test focuses on sustained transfer and may not reflect short requests or authentication time. Testing the actual app comes closest to your needs, but is also affected by the platform's workload and your account status. Use these signals together: if the entry point is unresponsive, check the route; if it responds but one app fails, check the destination; if a sustained download slows everything down, check capacity and queuing. One number cannot explain every symptom.

Route diagnostic results also need careful interpretation. Intermediate devices may deprioritize probe responses and appear unresponsive while still forwarding regular traffic. Suspect that segment only if the same issue continues at later destinations. A missing response at one hop does not prove that real traffic is being lost there. Most users do not need to share full network details to locate an issue. The error stage, access method and a repeatable task are usually enough to start a support conversation.

Choose the Next Step Based on Symptoms, Not Repeated Reconnects

If every app has problems at once, check local access and client status first. If only one platform is affected, check its service status, regional requirements and account messages. If only long-running tasks disconnect, look at idle timeouts, route changes and background restrictions. If performance drops only at busy times, compare sustained performance across topologies. Each case calls for different evidence. Repeatedly toggling the connection may temporarily reset its state, but it will not explain the issue and can make logs harder to interpret.

Changes to low-level settings such as MTU require a clear reason. Encapsulation adds overhead, and routes may handle larger datagrams differently, but a webpage loading problem does not automatically mean the MTU is wrong. Lowering it without evidence may increase fragmentation or processing overhead; raising it arbitrarily can prevent some content from getting through. Start with the service and client defaults. Only make a reversible change after support staff confirm the symptoms and where it applies, and avoid changing several low-level settings at once.

When contacting support, it helps to describe what works and where the problem starts. For example, browsing works on a route but uploads fail, or the same task disconnects only after a network switch. Include redacted error text and the stage where it occurred; do not share passwords, full subscription URLs or credential fields. Contact VPNGas through the user panel support ticket. A clear reproduction process can help identify route issues and prevent repeated configuration changes for an outage on the destination platform.

Device resources and battery life: comparing mobile devices

Network overhead on a device comes from more than encryption. System-wide traffic routing, rule matching, DNS resolution, data copying, logging and background keep-alives all use resources. The same protocol can behave differently across clients because they may use different network interfaces and scheduling methods. When discussing which protocol uses less battery, specify the client and system environment too. Conclusions based only on protocol names, without accounting for screen use, signal strength and workload, are hard to reproduce.

On Mobile, Check Radio and Background Activity First

Keeping data moving on a mobile device with a weak signal can use more battery by itself. Frequent small requests and keep-alives may also prevent the wireless connection from entering a lower-power state. Even if a protocol has low processing overhead, constant network activity can still affect overall battery life. Compare under the same access method and workload; don't compare idle standby on Wi-Fi with video streaming over mobile data.

Background restrictions can create another kind of false impression. To conserve resources, the operating system may pause an app or restrict its network extension, so the connection needs to recover when you return to the app. Check the allowed background activity, client notifications and network permissions. Don't start by disabling every power-saving feature. First confirm whether only a particular app is affected, then adjust the necessary permissions according to official guidance while keeping the device's normal power management in place.

On Desktop, Check Concurrent Workloads, Rules and Traffic Routing

Desktop devices often run browsers, sync tools, development environments and messaging apps at the same time. The number of connections and sustained background transfers may affect CPU and memory more than the protocol itself. Complex rule lists and verbose logging left on indefinitely also add work. For testing, temporarily limit activity to the necessary apps and reproduce the issue with a configuration from the user panel. Gradually restore your usual workload to find out whether a specific app is driving resource use up.

Keep Rules, Resolution and Logs Understandable

Split-tunneling rules determine which requests use which route. Incorrect rules can send different resources from the same app over different networks. If a login page works but its content does not load, the issue may be that resource domains are not being handled as expected, rather than a protocol problem. DNS resolution can also affect the destination address and content delivery choice. First confirm that you are using rules adapted for the service, then check the specific request. Avoid combining large numbers of rules from different sources and trying to diagnose the result by guesswork.

Logs can help identify the stage where an error occurs, but more logging does not mean better performance. Verbose logs are useful for briefly reproducing an issue, not as a permanent performance setting. Before submitting them, remove credentials, subscription URLs and sensitive destination details. Restore the usual logging level after testing to reduce unnecessary disk writes and noise. If resource use remains unusually high, check whether the client is stuck in a reconnect loop rather than assuming encryption is too demanding.

For battery comparisons, use the same task: continuous reading, receiving messages with the screen off or a streaming session in the same app. Check whether the task completes, whether the app recovers in the background and whether the device stays warm, then review the system's battery usage. A brief CPU spike right after connecting does not predict all-day battery life. Likewise, don't compare a cached app session with a cold start under heavier load. Consistent conditions make results meaningful.

VPNGas supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices; this does not mean each device has a separate data allowance. Download clients and subscriptions from the user panel download page. Sign in to access your subscription. Desktop and mobile devices can use different compatible setups, but keep your account and subscription secure. See the guide to securing your account and subscription links for more details.

Choose by use case: build a reversible selection process

Start by defining what you need, then look at the available combinations. Note the destination service, main tasks, devices you use and access environment. Decide what matters most: first response, sustained transfer, background connectivity or a consistent exit. Then choose from the routes the service actually offers, rather than picking a protocol first and searching for an incompatible configuration. For most daily tasks, a stable route, full client support and clear troubleshooting matter more than the protocol name.

Web Browsing and Everyday Work: Reduce Delays and Connection Confusion

Web browsing and work platforms make many short requests and often depend on a logged-in session. First check whether a cold start is smooth, multiple resources load together and the connection survives a brief absence. If the page layout appears but its content does not, check resource requests and routing rules. If you are repeatedly asked to verify your identity, check whether the exit changed and review the destination platform's security policies. Don't keep switching regions just to chase lower latency on every page load; a stable route is valuable too.

For collaboration apps, check whether they use the system proxy. Some tools manage their network settings independently, so a working browser does not prove they use the same route. Check the client and app documentation to confirm how traffic is routed before comparing protocols. When editing, submitting or uploading, verify after the connection recovers whether the server received the operation. No response on screen does not necessarily mean the remote service did not complete it; this is an important limit of app-side error handling.

AI APIs: Plan for the Exit and Error Handling

AI websites, developer tools and API calls are different kinds of access. API tasks may use long-lived connections, streaming output and concurrent requests; in addition to a stable connection, they depend on account permissions, quotas and server-side rate limits. First distinguish a connection failure from an error returned by the service or output that stops partway through. Infinite reconnects are not a solution to app-level errors: the remote service may already have accepted the request, so consider duplicate execution and charges before retrying.

For services that require a fixed exit, confirm that the service offers that capability. A route label staying the same is not a guarantee of a fixed IP address. VPNGas does not guarantee fixed exits, so developers should assess the actual route details and provide error handling. Set concurrency and timeouts based on the destination API documentation and the task, not the protocol name. See the guide to choosing routes and setting timeouts for AI APIs for a fuller checklist.

Streaming and Sustained Transfers: Match the Region, Then Check Continuity

For streaming, first make sure the exit region meets the platform's requirements, then consider sustained throughput during playback. Loading the homepage does not mean the catalog, sign-in and media resources are all available. Playback problems may also be related to the account or licensing region. Test the same content with the same quality settings, checking startup, seeking and continued playback; don't use a momentary download peak as a substitute for the actual experience. For more on catalog differences and testing, see our Streaming guide and analysis of Disney+ regions and connection stability.

File transfers depend more on sustained throughput, recovery from failures and local storage. A download that fills the access link can slow interactive tasks through queuing; manage concurrent tasks before changing protocols. Whether a large download can resume also depends on the app and remote server. Mobile work requires consideration of network switching and standby battery use. Choose a primary setup for reliable recovery and keep a backup for access compatibility issues; there is no need to force every device to use the same protocol.

Check Billing After Choosing for Performance

Protocol choice does not replace planning your data use. VPNGas monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they remain available until used and never expire. Sustained tasks and occasional use may call for different billing options. See the plans page for full prices and terms rather than inferring discounts from performance tests.

Keep a brief note of the final setup: which route combination you use for regular tasks, when to switch and how to restore the default configuration. VPNGas offers a 30-day money-back guarantee and accepts Alipay / WeChat Pay / USDT. No email address is required; a username and password are all you need to get started. Review the Terms of Service for the applicable terms. A good technical choice should make daily use easier to maintain, not leave behind a growing list of unexplained settings. A choice you can reproduce, roll back and explain is a choice well made.