Protocol and Route Technical Reference

REFERENCE / SELECTION MODEL

Start with a protocol selection framework

Protocol names are often treated as shorthand for route quality, which is the easiest way to reach the wrong conclusion. A protocol defines how the client and server establish a session, encapsulate application traffic, authenticate the peer, and continue transmitting through network jitter. The route determines which carrier networks carry the data, whether traffic detours between the entry and exit, and whether the path shares capacity with ordinary traffic during peak hours. A streamlined protocol on a heavily detoured route can still feel slow; a protocol with strong recovery on a stable dedicated route may not show all of its theoretical advantages. Separate the protocol layer from the path layer first, then assess whether they work well together.

For everyday use, break a connection into the device, client, protocol session, entry route, backbone path, exit route, and target service. The device provides the network environment, the client applies rules and takes over traffic, the protocol session sends application data to the entry, the route topology determines the path in between, and the exit represents the user when contacting the target service. If a webpage will not open while other apps still communicate, the issue may be a rule or the target service. If every app stalls at once, continue checking the local network, protocol session, and route. Layering the path makes it possible to troubleshoot without blindly changing every setting.

Start with the use case, not the protocol name

There is no universal protocol ranking outside a specific use case. Short webpages, long-form video, file transfers, remote sessions, and long conversations in AI Tools place different demands on a connection. Short webpages favor quick setup, long-form video needs sustained throughput and buffer recovery, file transfers require long-term stability, remote sessions are sensitive to momentary jitter, and AI Tools often combine short requests with continuous responses. First note the main apps, usual platforms, how often the network changes, and whether waiting, buffering, or battery drain is least acceptable. Once the requirements are clear, protocol differences become meaningful.

Also distinguish between “can connect” and “suitable for long-term use.” One successful handshake only shows that the device could reach the entry at that moment. It does not prove that the later path is free of congestion or that the session will recover smoothly after a mobile network change. Conversely, an occasional connection failure does not necessarily mean the protocol is unsuitable; DNS resolution, system time, network permissions, and entry status can all affect setup. Base the judgment on recurring patterns: is it slow only at startup or continuously after connecting; does one platform fail or do several behave the same way; is one route affected or are all routes on the same network affected?

The service covers 110+ countries / 190+ routes, supports Windows / macOS / iOS / Android / Linux, and has no limit on the number of devices online at the same time. This coverage gives you room to switch entry and exit points, but more routes does not mean you should switch constantly for every use case. A more reliable approach is to keep one primary everyday route, one backup route with a different topology in the same region, and choose the protocol based on the application. When something goes wrong, fewer variables make it easier to tell whether the difference comes from the protocol or the path.

REFERENCE / PROTOCOL FAMILIES

Trade-offs among six connection protocols

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC are not simply different names for the same design. They emphasize different aspects of encapsulation complexity, authentication, underlying transport, session recovery, and client maturity. Compare them by checking complete client support, matching server parameters, and whether the underlying network favors a stable stream or transport that tolerates packet loss better—not merely by asking which is newer. The protocol is only one part of the system; implementation quality and route conditions can amplify or reduce theoretical differences.

Shadowsocks: streamlined design for establishing a baseline

Shadowsocks is relatively straightforward, widely implemented, and usually easy to understand across the processing path. It works well as a baseline protocol: when you need to determine whether the route itself is healthy, starting with a simple configuration and fewer additional layers reduces troubleshooting variables. Its strength is not automatic adaptation to every complex network, but a clear path with less extra processing. For ordinary web browsing, file synchronization, and video on a stable network, it often behaves predictably. If the network has persistent packet loss or frequent changes, the experience depends more on connection recovery and client implementation; streamlined encapsulation alone cannot remove path problems.

VMess: richer session details and broad compatibility

VMess provides a relatively complete mechanism for session authentication and transport combinations, so it is often used where several client environments must be supported. The trade-off is a more complex setup and parameter relationship. Troubleshooting requires confirming that the client and server interpret the transport method, identity details, and time state consistently. It is not inherently faster; actual speed still depends on the route and transport. VMess is best suited to a stable client ecosystem with parameters distributed centrally, rather than manual mixing of options whose meanings are unclear.

Trojan: carrying data over a standard secure session

Trojan typically runs over a standard secure transport session, so setup includes certificate validation, hostname matching, and encrypted-session negotiation. Its advantage is a clear transport boundary, with mature support for these mechanisms in many system network stacks. It also means that system time, DNS resolution, the certificate chain, and intermediate network behavior can affect the handshake. If setup takes a long time but transfer is normal afterward, check DNS and the handshake path before attributing the issue to exit bandwidth. For long web sessions, Streaming, and ordinary downloads, Trojan generally depends on underlying stability and route quality.

VLESS: less internal overhead, greater reliance on the outer layer

VLESS emphasizes a leaner internal protocol and delegates some security and transport responsibilities to the outer layer. This makes it easier to combine different transports for different route conditions, but also makes a correct combination more important. Comparing the VLESS name while ignoring the outer transport misses a key part of the user experience. It is well suited to centrally managed subscription parameters and clients with complete support for the relevant combinations. When troubleshooting, check identity details, outer security sessions, transport, and routing rules separately; a simpler protocol core does not mean the full configuration is automatically simple.

Hysteria2 and TUIC: transport for fluctuating networks

Hysteria2 and TUIC place greater emphasis on maintaining continuous transfer across networks with fluctuation, packet loss, or frequent changes, typically using modern datagram-based transport. They can avoid the prolonged waiting that some traditional long-lived streams experience after an isolated loss, but route quality still matters. Connections may be affected when network equipment restricts datagrams or system background policies repeatedly freeze the client. These protocols are better suited to mobile networks, visibly unstable cross-carrier paths, long-form video, and sustained data flows. Potential trade-offs include more active retransmission and keepalive behavior, along with higher demands on client implementation, system network permissions, and entry configuration.

The right conclusion from protocol comparisons is usually not “one protocol is always best,” but “which behavior fits the main application on this device, network, and route.” If you change the region, entry point, and client at the same time as the protocol, you cannot know what caused the improvement. Keep the route and application fixed while changing only the protocol; when comparing topologies, keep the protocol fixed while changing only the route. Controlling variables is more valuable than memorizing a protocol ranking.

REFERENCE / CONNECTION COST

Connection setup and resource use

The “startup speed” users feel is not simply the time from pressing Connect to seeing a connected status. The full process may include reading the subscription, selecting rules, resolving the entry hostname, establishing the underlying connection, authenticating the server, negotiating the transport session, and creating a system proxy or virtual network interface before the first application request finally travels through the route. Waiting at any stage feels like a slow connection. Distinguish between a frozen client interface, a completed connection with a webpage still unopened, and a slow first request followed by normal requests. These point respectively to client initialization, protocol handshake, or DNS and path warm-up.

More handshake steps do not necessarily mean a slower experience

Protocols that include a standard secure session require more validation during initial setup, but can usually reuse the session afterward. With continued use of the same route, the initial cost is spread across later requests. Conversely, a streamlined protocol may start directly, yet if the client frequently destroys connections or the system repeatedly pauses the process in the background, users still pay the setup cost again. Evaluate first connection, continuous app use, recovery after sleep, and recovery after a network change—not just one button response.

DNS resolution is also often mistaken for a protocol-speed issue. When an entry uses a hostname, the client must obtain its address; the target app may also need to resolve its own hostname. If the local resolver is unstable, the client may show Connected quickly while the browser remains stuck before loading. Switching protocols may occasionally help for a moment because it triggers fresh resolution or uses a different cache, not because the protocol repaired DNS. Compare several apps, reconnect after refreshing the subscription, and check whether the system can resolve common sites normally to narrow the cause.

CPU, memory, and the system network stack

Resource use comes from encryption, encapsulation, rule matching, data copying, logging, and the client interface; it should not all be attributed to the protocol name. Desktop devices generally have more CPU and memory, so differences may not appear in lightweight webpages. Mobile devices are more affected by background limits, heat, and battery, making differences easier to see during continuous video, file synchronization, and many concurrent requests. Oversized rule sets, verbose logging left on, and multiple network tools taking over traffic can create a larger resource burden than the protocol itself.

Virtual network interface mode can take over traffic from more applications and suits unified routing, but it also makes the client handle more data. System proxy mode has a more direct path, but depends on whether each app follows the system proxy. If only some apps cannot communicate, check the takeover mode and split-tunneling rules first. If all apps work but the device stays hot, check for forwarding loops, duplicate takeover, repeated reconnections, or excessive logs. Giving all traffic to the client does not automatically make it more stable; clear rules and a single primary traffic manager matter more.

In KdVPN, subscriptions are provided centrally through the user panel. Use the parameters delivered by the subscription as the source of truth, avoiding omissions of outer transport or identity details during manual copying. If you suspect the local configuration is outdated, retrieve the subscription again and refresh it in the client instead of guessing at parameters one by one. No email address is required for registration; a username and password are enough. Treat the subscription link as an account credential and protect it carefully. To verify import and activation, see how to check whether a connection is working, confirming the exit and application traffic step by step.

REFERENCE / MOBILE POWER

Mobile battery use and background behavior

Mobile battery drain cannot be explained by the protocol name alone. Screen state, signal strength, switching between Wi-Fi and mobile networks, concurrent apps, system background limits, and client keepalive behavior all affect the result. With a weak signal, the device works harder to maintain the wireless connection. Persistent packet loss makes the client retransmit and keeps the wireless module active longer. Frequent background wakeups add session-maintenance cost even when each request carries little data. Evaluate protocol choices alongside the system battery report, network conditions, and actual app behavior.

Continuous activity and frequent wakeups are different problems

Long-form video and file synchronization keep the network continuously active, so focus on smooth transfer and whether packet loss causes repeated work. Push notifications, background sync, and scattered requests wake the device frequently, so focus on whether the client can retain the session and whether the system repeatedly freezes and restarts the connection. Datagram-based protocols may maintain session state more actively and recover faster during network changes, but an uncoordinated client keepalive policy and system background rules can also cause extra wakeups. Traditional stream-based connections behave clearly on stable networks, yet may need to reconnect after a network change.

When assessing battery use, first check for repeated reconnections. A client state that constantly flips between connected and disconnected often consumes more power than a stable session. Repeated reconnections can come from an unreachable entry, system limits on background networking, multiple network tools competing for the interface, an unstable Wi-Fi connection, or subscription parameters that were not updated correctly. Changing protocols again only changes the retry behavior; it does not remove the root cause. Close other traffic-management tools, confirm the client has the required system permissions, and observe whether the connection holds on the same stable network.

Platform differences come from system policies

iOS applies strict lifecycle management to background networking and virtual network interfaces, so clients typically run through system-provided network extensions. Android background behavior varies by system implementation, and battery-saving settings may restrict continuous client operation. Windows and macOS are better suited to long-running desktop sessions, but sleep, network wake, and security software can still affect connections. Linux generally offers more direct network control while requiring users to manage service processes, routes, and DNS explicitly. Differences on the same protocol across platforms often come from how the system schedules the client, not from a change in the protocol algorithm.

Create comparable conditions for observing battery use

Do not label a protocol as power-hungry based on one brief experience. A more reliable method is to use the same device, route, and app behavior under similar network conditions and observe each option separately. During testing, close unrelated large sync jobs, keep the client log level consistent, and confirm that no other network tool is active. The goal is not a seemingly precise percentage, but whether battery use coincides with heat, reconnections, transfer stalls, or background failure. If consumption rises while transfer remains stable, the app itself may simply be using more data. If higher consumption occurs with reconnections, address session stability first.

The boundary between mobile and Wi-Fi networks is where differences are easiest to expose. After leaving Wi-Fi coverage, the system changes network interfaces and addresses, and the old session may fail. Implementations that support session migration or rapid recovery are usually more resilient, but the target app may also rebuild its own connection. If only one app stops after the switch, restart that app’s request first. If every app stops, reconnect the client. If the client also cannot establish a session, switch to a backup route in the same region to check whether the entry is reachable from the current network. This order avoids resetting every setting after each network change.

REFERENCE / ROUTE TOPOLOGY

Route topology: direct, relay, and dedicated

The protocol determines how data is placed into transport units; route topology determines which path those units follow. The core difference between direct, relay, and dedicated routes is not how sophisticated the names sound, but how much control the service has over the entry, cross-network path, and exit. Geographic distance gives only a rough direction. Actual paths are also shaped by carrier interconnections, exit planning, and peak-hour scheduling. A nearby region can perform worse than a farther one if traffic detours, and two entries in the same city can differ because they use different access networks.

Direct: simple path, more exposed to public-network changes

A direct route connects the device straight to an entry in the target region, relying mainly on public-network routing along the way. Its structure is simple, with little extra forwarding, and it can respond directly when the local carrier network has good interconnection with the entry. The limitation is that the server has less control over the intermediate path; carrier changes, interconnection congestion, and temporary detours are passed on to the user. Direct routes are a low-complexity option and a useful way to assess whether the public path from the local network to the target region is healthy. If direct routes in the same region differ greatly across networks, examine carrier interconnection rather than assuming the exit server itself is unpredictably fast or slow.

Relay: enter through a controlled point, then reach the exit

A relay route first connects the device to a suitable entry, which then forwards traffic to an exit in the target region. This can avoid some poor public-network segments and separate user access from the international leg. The relay adds a scheduling step and variables such as entry status, the entry-to-exit path, and forwarding capacity. When designed well, it can provide more consistent paths across local networks. If the entry is congested or the forwarding segment has problems, you may see an entry that responds quickly while the application remains slow. Troubleshoot the device-to-entry, entry-to-exit, and exit-to-target segments separately.

Dedicated: greater path control and steadier scheduling

The main value of a dedicated route is more controllable path and capacity scheduling, not the elimination of geographic distance. It generally reduces unpredictable public-network detours and limits the impact of changes in cross-carrier interconnection on the middle segment. A dedicated route still needs public-network access and an exit service. Unstable wireless access, a slow target service, or congestion between the exit and target can still cause stalls. Dedicated routes are therefore better suited to long sessions, consistent peak-hour performance, and sustained transfer, but they should not be understood as making every stage independent of outside conditions.

When choosing a region, consider the target service’s location and content requirements first, then assess path quality. Frequent switching just to pursue a shorter apparent distance can repeatedly change app login state, content region, or exit identity. Everyday use is better served by fixing one primary region and comparing different topologies within it. Switch the exit only when the target service clearly requires another region. This preserves app sessions and provides a stable baseline for troubleshooting.

KdVPN’s full coverage and route types are listed on the route list. The page provides regional information for 110+ countries / 190+ routes. When reviewing the list, filter regions by purpose first, then choose primary and backup routes by topology. Do not equate the number of routes directly with the speed of a single connection; coverage offers more path and exit choices, while actual performance still depends on the current network, protocol, and target service.

REFERENCE / LOSS AND CONGESTION

How packet loss and peak-hour congestion form

Packet loss means transmitted data does not arrive as expected. Congestion means a part of the path is temporarily carrying more traffic than it can process smoothly. They often occur together but are not the same thing. Wireless interference, signal changes, router queues, cross-network interconnection, and exit pressure can all cause packet loss. Congestion more often appears as increased waiting, growing queues, more retransmissions, and fluctuating throughput. Peak-hour issues are difficult to identify because local access, carrier interconnection, the entry, middle segment, exit, and target service may all be under pressure at the same time.

Why webpages still load while video keeps buffering

Web requests usually consist of many relatively small resources, so a browser may display content already received even when some resources take longer. Video requires a continuous data supply; once effective throughput falls below playback demand, the buffer shrinks and eventually stalls. Long conversations and remote sessions are more sensitive to momentary waiting: even with sufficient average throughput, a brief queue can make interaction feel sluggish. “The webpage opens” only proves that the path can transfer data; it does not prove that sustained transfer and interactive latency are normal.

Traditional stream-based transport retransmits lost data and adjusts its sending pace. If a queue becomes too long on part of the path, later data may wait for an earlier gap to be filled, producing a sudden stall. Modern datagram transport can let different data flows recover more independently, reducing the chance that one missing segment holds up everything, but lost data still has a retransmission cost. A protocol can improve recovery behavior; it cannot create path capacity that does not exist. If the entry or middle segment is already congested, a more proactive transport may change the shape of the stalling without fundamentally increasing available capacity.

A layered approach to peak-hour issues

If local ordinary websites and every route slow down at the same time, check local access and the carrier network first. If only routes in one region slow down while other regions remain normal, the issue is more likely concentrated in that region’s path or exit. If different protocols show similar stalls on the same route, prioritize the route over the protocol. If only one target service slows while other sites and apps work normally, suspect the target service, interconnection from the exit to the target, or the app’s regional policy.

Speed tests also do not perfectly represent real applications. A speed test continuously sends large amounts of data and can push a route into high load for a short time. Webpages and conversations care more about response time, while video includes prefetching and buffering. One speed test cannot represent every app. More useful records include the network type, route region, topology, protocol, affected app, and what changed after switching to a backup route in the same region. Recording these conditions turns “it feels slower” into a repeatable problem description.

Order of operations matters more than repeated refreshing

When stalls persist, confirm the local network first, then switch to a backup route with a different topology in the same region. If the issue remains, switch protocols to compare recovery behavior, and change regions only at the end. This order starts with variables that have a smaller scope while preserving the app’s region and login session. If you immediately cycle through regions, protocols, and clients, even a recovery will not reveal the cause, and the next incident will require starting over.

To confirm that traffic is actually using the selected route, read how to check exit IP and DNS. If the client shows Connected but the exit has not changed, address traffic takeover and routing rules first. If the exit has changed but the app is still slow, move on to the route and target service. Separating “was traffic taken over?” from “is it smooth afterward?” is the key boundary in the troubleshooting process.

REFERENCE / SCENARIO CHOICE

Choose protocols and routes by use case

You do not need to try every protocol in rotation. Set a preference based on the main use case, then validate it with a consistent method. Everyday browsing, AI Tools, Streaming, file transfer, and mobile work have different bottlenecks, and the primary and backup routes should not be identical. The goal is not to find one connection that wins under every condition, but to establish a stable baseline for common tasks and a clear alternative when the network changes.

Everyday browsing and short requests

Web browsing involves DNS resolution, multiple parallel requests, and reuse of short connections. Start with a protocol whose setup is clear and whose client support is mature. Shadowsocks can serve as a simple baseline; Trojan, VMess, or VLESS work well when the subscription is centrally configured and the client fully supports it. For routes, choose a direct or relay path with a sensible region and clear routing rather than selecting a more distant region for the protocol name alone. If the first opening is slow but later requests are normal, focus on DNS and session reuse. If every page keeps waiting, examine route congestion and rule matching.

AI Tools and long conversations

AI Tools typically combine short requests with long sessions that continuously return content. The connection must remain stable for extended periods, and the exit should not change frequently. Prefer a relay or dedicated route with limited path fluctuation and keep the usual region fixed. For protocols, start with a mature client and stable long-session behavior. If mobile-network changes are frequent, compare the recovery behavior of Hysteria2 or TUIC. When a response stops midway, do not immediately sign in again. Check whether other webpages work, whether the client session is still active, and whether a same-region backup route can continue the session.

For network requirements around ChatGPT registration, login, and long sessions, read the ChatGPT stable access guide. These scenarios especially benefit from avoiding frequent exit changes. Choose routes for session continuity rather than switching to a completely new region at every brief fluctuation.

Streaming and sustained transfer

Streaming depends more on sustained effective throughput and recovery after packet loss. First choose a relay or dedicated route with a stable path to the target content region, then decide whether the current network suits a traditional stream-based protocol or Hysteria2 and TUIC for fluctuating networks. Playback that starts normally but buffers later is usually more indicative of sustained-throughput trouble than a handshake issue. When switching, keep the region fixed and compare routes within it. Changing regions also changes the content library, exit, and path, making the transport issue harder to isolate.

Services such as Disney+ also involve regional libraries and subtitle differences, so technical connectivity does not guarantee identical content. See Disney+ region and route comparison for relevant region choices. Keep the same exit during viewing whenever possible to avoid repeated regional checks by the app.

File transfer and synchronization

File transfer prioritizes sustained throughput, failure recovery, and stable background operation. On desktop platforms, prefer a stable relay or dedicated route and disable unnecessary verbose logging to reduce extra client-interface and disk-write overhead. If a transfer starts fast and then drops noticeably, check path congestion, device sleep policies, and limits imposed by the target storage service. Protocol switching can compare packet-loss recovery, but keep the same file, exit, and time window so changes in the target service are not mistaken for protocol differences.

Mobile work and frequent network changes

Mobile work often switches between Wi-Fi and mobile networks, so session recovery and background survival matter most. Hysteria2 and TUIC are worth comparing first, provided the client and current network fully support them. If datagram transport is unstable on the current network, return to a mature stream-based option and recover through reconnection. For mobile devices, choose a relay or dedicated route with a stable path as the primary route, and keep a same-region backup with a different entry. During a switch, avoid changing the exit region if possible.

Plans do not change the way protocols are evaluated. KdVPN monthly subscriptions are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic resets monthly on the activation date, and mid-cycle upgrades are prorated by the remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. Choose any option based on actual usage. See the plans page for full rules. The protocol recommendations in this article concern connection behavior only and do not imply that you need to change your billing plan.

REFERENCE / DIAGNOSTIC FLOW

Troubleshooting and long-term maintenance

Stable use depends on a repeatable diagnostic order, not a large collection of unverified configurations. When a problem occurs, identify its scope first, then work layer by layer from the device toward the target service. The scope may be one app, similar apps, all apps, one route, routes in one region, or every route. The clearer the scope, the easier the diagnosis. Saying only “it won’t connect” does not distinguish DNS, routing, entry, protocol, or target-service issues, and encourages changing several variables at once.

Start with the local network

Temporarily disconnect the client first. Confirm that the local network can reach commonly used local services and observe whether the Wi-Fi connection changes frequently. If the local network itself is unstable, fix access first. Reconnect the original route and check whether the client completes the session. If it cannot, check whether the subscription is refreshed, the system time is correct, network permissions are complete, and another tool is using the system proxy or virtual interface. Do not change app settings at this stage because app traffic has not yet entered a working route.

Confirm that traffic is being managed

After the client shows Connected, verify it with a browser and another app. If the browser works but the other app does not, the issue is likely whether that app follows the system proxy, the scope of virtual-interface takeover, or split-tunneling rules. If no apps work, check system routes, DNS, and connection status in the client logs. If the exit check shows no change, continue troubleshooting traffic takeover. If the exit has changed, the entry and protocol are basically working, so focus on sustained route transfer and the target service.

Use a same-region backup route to isolate path issues

Keep the protocol and exit region unchanged, switching only to a different entry or topology in the same region. If the backup route works, the original path or entry is more suspect. If every route in the region fails, compare protocols. If different protocols behave the same, prioritize the path. If one protocol family consistently fails to establish while others work on the same route, check support for the underlying transport on the current network, the client implementation, and protocol parameters. Change regions last to determine whether the issue is confined to the target region.

Validate the target service separately

When webpages, file transfers, and other apps work but one target service fails, do not keep resetting the entire client. First check whether the service is reachable in a browser or on another device, then inspect app cache, login session, and regional requirements. The target service may independently evaluate the exit region, account status, or its own maintenance state. A route reaching the target does not mean the target will accept the current request; conversely, an app error does not prove that the protocol session has disconnected.

Maintain a simple baseline

Long-term maintenance does not require keeping many duplicate routes. Keep an everyday primary route, a same-region backup, and one emergency option with a different topology, recording their protocols and main use cases. After a subscription update, confirm that the primary route still connects, then check the backup. After a client upgrade or system network change, validate the same baseline set again. A baseline is not meant to guarantee that nothing changes; it gives every change a point of comparison.

Protect subscription links and account credentials separately. Do not expose them in public documents, screenshots, or group chats. Account registration requires no email address; a username and password are enough. If you use multiple devices, the service has no limit on simultaneous online devices, but each device should use a controlled client configuration, and unused local copies should be removed promptly. Client entry points for Windows / macOS / iOS / Android / Linux are provided centrally in the user panel; avoid copying configurations from unknown sources.

For fees, use the plans page and user panel as the source of truth. KdVPN supports Alipay / WeChat / USDT and provides a 60-day no-questions-asked refund. Choose a monthly subscription or a traffic package that never expires based on usage and frequency, not protocol type. Protocol, route, and plan are separate layers: the protocol determines connection behavior, the route determines the path, and the plan determines available traffic and billing. Managing them separately reduces irrelevant variables during troubleshooting.

For account security and subscription protection, read the VPN security guide for beginners. If you only need to import the client again, return to the quick-start guide. The core principle of this page is simple: define the scope first, then proceed through the device, traffic takeover, protocol, route, and target service in that order; change one major variable at a time; after recovery, record the adjustment that actually worked instead of keeping every temporary change.