Shadowrocket
Protocol Selection and Settings

01 / Distinguish Protocols, Transport, and Rules

The Protocol Type Must Match the Server

Selecting a type in Add Server determines the format the client and server use to communicate. Names such as Shadowsocks, VMess, VLESS, and Trojan describe different authentication and data-handling methods—not interchangeable speed settings. If your existing details specify VLESS, do not choose Trojan just because it seems simpler. The server must support the same protocol, credentials, and transport combination for a connection to work.

It helps to think of a connection in four layers. At the bottom is network reachability between your device and the server, followed by TCP, UDP, or a transport built on them; above that are protocol authentication and optional TLS; finally, the request reaches its destination. Rules in Config determine which policy handles each request—they do not fix a server password. Keeping these layers separate helps avoid repeatedly changing DNS when authentication is failing, or switching protocols when the issue is a routing decision.

Check the Address, Identity, and Transport Separately

The server address identifies the connection endpoint, and the port identifies the service at that endpoint. The address can be a domain name or an IP address; a domain name adds a DNS lookup step. Authentication fields prove that the connecting client is allowed to use the endpoint and may appear as Password, UUID, or a key. Transport fields describe how the request reaches the server, such as a WebSocket Path, HTTP Host, or another service name. Even with a correct address and credentials, a mismatched transport path can interrupt the handshake.

Importing a subscription usually fills these fields in the server entry. For initial troubleshooting, preserve the imported values and compare them with your existing details one by one. Do not clear options you do not recognize or combine parameters from another entry. If the interface does not show additional transport fields, that combination may not need them, or the fields may depend on the selected type. Follow the current app interface and your existing configuration rather than copying an unrelated example.

Compare Speed and Battery Use Under the Same Conditions

On iOS, protocol processing uses CPU resources, but wireless signal strength, retransmissions, screen brightness, and background activity can matter just as much. A protocol with a short handshake is not necessarily faster for large downloads, and one that quickly fills the available bandwidth may not suit long periods of low-traffic standby. Short connections make handshake and DNS lookup costs more noticeable; sustained downloads reveal more about bandwidth, congestion control, and server load. State what kind of task you are measuring before comparing results.

Choosing a protocol does not change the underlying network conditions at the server. The same protocol can have very different latency and throughput at different endpoints; different protocols can also slow down together if they share a congested exit. For a fair comparison, use the same device, network, destination, and test window. Pause other high-bandwidth activity, and record whether the connection succeeds, how long the first request takes, and how stable sustained transfers are. Do not treat one test's ranking as a permanent result.

02 / Shadowsocks: Match the Encryption Method and Password

A Proxy-Focused Connection Design

Shadowsocks is designed to carry proxy traffic with a relatively straightforward setup, adding authentication and encryption between the client and server. It generally does not require users to understand a complete virtual network topology; configuration centers on the server address, port, encryption method, and password. Fewer fields can make an entry easier to check, but they do not make every combination valid. The encryption method is part of protocol compatibility.

Traditional configurations often include encryption method names that indicate the algorithm, mode, or key length. The method must exactly match the server's; do not choose one based on which sounds faster for your phone. Different methods may handle passwords and format messages differently. The client saving an entry does not mean the server will accept it. If a protocol variant requires a different credential format, use the existing configuration rather than substituting an ordinary password.

Check the Four Core Fields

Enter the actual server endpoint in the address field; do not paste an entire share link there. Use the port provided by the server, and make sure you have not copied spaces, a colon, or explanatory text along with it. Preserve the exact case and symbols in Password; chat apps can add line breaks when copying. Check Method character by character. If you only have a share link, import it using the guide and review the parsed result. This is usually less error-prone than manually splitting out encoded values.

Some deployments also specify plugins or transport settings. These are part of the connection path, not cosmetic options. If the server requires additional encapsulation, the client needs matching parameters to communicate in the same format. Conversely, do not add extra encapsulation to a standard endpoint. If you are unsure, ask your service provider what a field is for. Do not replace existing details with a so-called universal value found online, or disable checks instead of confirming compatibility.

Working TCP Does Not Mean UDP Works

Shadowsocks can forward TCP and UDP traffic, but availability of either depends on the server, network path, and client entry settings. A website loading only shows that the request path used at that moment worked; it does not prove that an app requiring UDP will work. If websites load but a real-time app fails, first check which transport the app uses and whether the server supports it. Do not immediately change the encryption method.

UDP datagrams have size limits, and extra encapsulation reduces the available payload. If small packets work but large packets or sustained traffic fail, consider path MTU, packet loss, and fragmentation. Repeatedly changing Password is unlikely to help: an authentication issue would not reliably occur only with packets of a particular size. Note whether all destinations fail or only a specific task, then use a simple request through the same server as a comparison to narrow down the issue.

Assessing Processing Overhead on iOS

With well-matched hardware and implementation, modern authenticated encryption methods can handle substantial traffic efficiently. Actual performance still depends on server capacity and network bandwidth. Sustained high throughput can generate more heat as the device encrypts and sends or receives data over the wireless network. During standby, check whether traffic is actually flowing. A small number of protocol fields does not prove that a protocol always uses less battery, and device heat cannot be attributed entirely to one algorithm.

For troubleshooting, keep a copy of the original entry, then verify the address, port, Method, and Password one by one. Use Connectivity Test and a request to an actual destination as separate checks. If all requests fail, start with the endpoint and credentials. If only a particular app has issues, check UDP, DNS, and routing. For a broader overview of these protocols, see Protocol Types: An Overview. Use your existing server details when configuring an entry.

03 / VMess and VLESS: Transport Matters as Much as Identity

Similar-Looking Settings Do Not Mean the Same Protocol

VMess and VLESS often both use a UUID as an identity field and can each use different transports, so they may look similar at first. VMess combines user authentication with its own data protection mechanisms. VLESS keeps its protocol handling more minimal and relies on a compatible security transport for data protection. Their message formats and authentication flows differ. A matching UUID format does not mean you can connect by changing only the type.

A UUID identifies a user; it is not a server domain name or display name. Copy the complete value without missing characters or invisible spaces. Some configurations also include fields for authentication or compatibility, which should not be filled based only on an old guide. Some historical VMess parameters are not required by every current configuration. If your existing details do not match the interface, check the configuration source and supported combinations before adding a value yourself.

Transport Determines How the Server Receives a Connection

The same protocol can run over different transports. A direct TCP setup typically has no WebSocket path. With WebSocket, Path and Host may determine which backend receives the request; other transports may use different service identifiers. These fields adapt the transport—they do not replace the UUID as another password. Omitting transport settings after entering only an address and UUID is a common cause of failure when an import is incomplete.

Preserve the leading slash, letter case, and any existing query string in Path; it is not a note for users to read. Host can differ from the server address: Host may be used for application-layer routing, while the server address is used to establish the network connection. If TLS is enabled, a Server Name or SNI may also be needed for the secure handshake. These values can sometimes be the same, but they have different roles. Enter each according to the configuration instead of changing them all to the server's IP address for consistency.

A Minimal VLESS Protocol Does Not Mean You Can Skip the Security Layer

When discussing VLESS, distinguish between “the protocol itself does not provide a particular type of encryption” and “the connection has no protection.” Actual security depends on the security transport and authentication mechanism used with it. The protocol name alone does not determine security, and a note in the interface that a setting is unencrypted is not a reason to disable TLS. Preserve the required combination if the server specifies one. If the details are incomplete, get the missing information before connecting.

Some entries include options such as Flow. These correspond to specific operating modes; they are not general-purpose performance switches. An incorrect value can break the connection after authentication or cause the server to reject it outright. Use the existing share information as your reference, and confirm that the current Shadowrocket interface supports the combination. If the interface has no corresponding option, adding the value to a remark will not make it work. Check whether the server provides another compatible endpoint.

Handshake, Clock, and Mobile Network Changes

Authentication flows that validate time may be affected by a device clock that is out of sync. If the endpoint is reachable but authentication keeps failing, check that the system date and time are correct—but do not treat the clock as the explanation for every failure. With TLS and additional transport layers, the first request may also involve a multi-stage handshake. Once a sustained transfer is established, these fixed costs are spread out, so the time to load a webpage and the speed of a large download may produce different rankings.

When switching between Wi-Fi and cellular on iOS, existing connections may need to be re-established. Check whether new requests succeed after the network recovers rather than expecting every in-progress download to continue without interruption. To compare VMess and VLESS, keep the transport and server conditions as consistent as possible; otherwise, differences may mostly reflect WebSocket, TLS, or endpoint load. When examining a VLESS entry, save the original first and change only one field at a time when you have a specific reason.

04 / Trojan: Understand Password Authentication Within TLS

TLS Provides the Secure Channel; the Password Determines Access

Trojan uses an established TLS channel to carry proxy traffic, then performs the corresponding authentication and request forwarding inside that channel. Keep two checks separate: first, the client must confirm it is connecting to a trusted TLS service; second, the service must confirm that the client's password is valid. A valid certificate only shows that the TLS handshake met its verification requirements. It does not mean the proxy password was accepted, and neither check replaces the other.

This explains why different problems can all appear to happen while “connecting to the server.” A wrong address or port may prevent a TCP connection; a mismatched Server Name may cause certificate verification to fail; an incorrect Password may be rejected after TLS is established. Check the fields associated with the stage where the failure occurs. Do not attribute every interruption to a password error, or disable certificate checks to hide a domain configuration problem.

The Connection Address and Certificate Name Can Differ

Address tells the client where to send the network connection, while Server Name or SNI identifies the server during the TLS handshake. When connecting by IP address, the server certificate may still be issued for a domain name, so the existing configuration may require a separate name. Certificates also have an expiration date, a chain of trust, and a covered-name range. A website opening in a browser does not prove that the proxy endpoint uses the same port, certificate, or routing configuration.

When a server hosts multiple services, SNI may also determine which certificate or backend it selects. Changing it to a popular website domain usually will not fix the problem and may route the request to an unrelated service. Use the value from your existing configuration. If a previously working setup suddenly reports a certificate error, check the device clock, server certificate status, and any endpoint changes. Keep the error details and ask your service provider to verify them.

Additional Transport Settings Must Also Match

Trojan entries do not always use only the most basic fields. Some server deployments also require a matching transport and path beneath the TLS layer. Follow your existing details instead of combining fields from another Trojan entry. After importing a subscription, first confirm that the app recognized the type and transport correctly. When entering details manually, record the address, port, password, security-layer name, and every explicitly required additional field separately.

Passwords are case-sensitive credentials. Spaces, line breaks, or substituted symbols during copying can cause authentication to fail. Do not use a subscription download token as a Trojan password, or treat an entry remark as a username. A subscription address and server credentials are different things: the former retrieves configuration, while the latter connects to a server. Successfully updating a subscription only shows that configuration data was retrieved; it does not prove that every server in it is currently reachable.

Speed and Battery Use on iOS Depend on How You Use It

TLS is a mature capability in mobile operating systems, but that does not mean it has no cost. Establishing a secure channel requires a handshake, which can be more noticeable when creating many short connections. During sustained transfers, throughput depends more on the network, encryption processing, and the server's forwarding capacity. Additional transport layers also add encapsulation and connection-management overhead. It is not accurate to say that Trojan is always faster or slower than another protocol.

Assess battery use over a representative period. A short download may draw more power momentarily but finish quickly; repeated failed reconnects may keep waking the network even when throughput is low. If standby battery drain seems unusual, first check for background requests, repeated retries, frequent network changes, and On Demand triggers. The protocol name alone cannot explain background activity, and changing the password will not stop retries.

A useful troubleshooting sequence is to connect through the current endpoint, try an ordinary destination that should already be reachable, then test the actual service. If the connection itself fails, check the address, TLS, and authentication. If only one destination fails, check DNS, rules, and the destination's response. For a step-by-step guide to “connected but no websites load,” see Four Checks When the Connection Is On but There Is No Internet instead of repeatedly changing TLS settings.

05 / HTTP and SOCKS5: A Proxy Interface Is Not an Encrypted Tunnel

Understand the Difference Through Their Application-Layer Roles

HTTP proxies came from application-layer request forwarding. They can handle ordinary HTTP requests and use CONNECT to establish a byte stream to a destination. SOCKS5 offers a more general way to specify destination addresses and connection commands; it does not require all carried data to use a web protocol. These are proxy interfaces. Their names alone do not mean that the connection between your device and the proxy server is encrypted; verify the security layer separately.

This is separate from whether the destination website uses HTTPS. HTTPS can protect the relevant application data between your device and the destination, but the proxy endpoint may still be able to see information such as the connection destination. The connection and authentication to the proxy have their own security boundaries. If you use an HTTP proxy with TLS, check the certificate and server name. If your existing details specify a standard proxy, do not enable TLS in the client and expect the server to adapt automatically.

Username, Password, and Server Access Rules

Both HTTP and SOCKS5 may use a username and password, or rely on server access controls to determine who can connect. Enter the details you were given; do not assume that leaving fields blank will work. A proxy that permits connections from a particular network may not accept them when you switch to cellular. If it stops working after a network change, check the server's access rules and credentials together rather than assuming the Shadowrocket entry is damaged.

Do not include an extra protocol prefix or path in the server address unless the interface explicitly asks for a full URL. Do not infer the port from the destination website's address. If your details are for a company or personally managed network, confirm which destinations and uses the proxy permits. Some endpoints are intended only for specific apps or network areas. Successful authentication once does not mean the proxy can forward traffic to every internet destination.

Who resolves the domain changes the result

Before a request reaches the proxy, the client may resolve the destination domain to an IP address or send the domain to the proxy to resolve. These approaches affect where resolution occurs, the errors you may see, and how domain-based rules are evaluated. SOCKS5 support for domain-name addresses does not mean every request is necessarily resolved on the server. Shadowrocket DNS and routing settings, the app's request method, and the implementation can all play a part. When troubleshooting, compare a request by domain name with one to a known address.

Similarly, a working website does not mean real-time communication will work. Standard HTTP CONNECT is traditionally used mainly for TCP. SOCKS5 has UDP ASSOCIATE, but the server, client configuration, and network between them must all support it. If the task depends on UDP, first confirm that the endpoint explicitly provides this capability. Without that support, changing a destination port will not add it; you need a compatible connection method from the existing server.

Use Cases and iOS Performance

If your existing details are for an HTTP proxy provided by your workplace or a SOCKS5 endpoint in a personal environment, choosing the matching type is usually more appropriate than trying to change it to another protocol. The point is to match the service interface you have, not to pick a name that sounds more general. If the endpoint is intended only for a trusted local network, treat that network boundary as part of the configuration. When the connection environment changes, reassess authentication protection, network reachability, and permitted destinations.

Less protocol-level processing does not guarantee lower overall battery use. A connection without additional encryption may reduce some computation, but the destination's own TLS, network retransmissions, and app request frequency still apply. A slow proxy server can keep the device's wireless connection active for longer. For a useful comparison, record success rate, request wait time, and task completion time. Do not treat an ordinary proxy as the answer for every use case based on a single latency test.

If only some destinations are accessible, first check the proxy's access policy and destination port restrictions, then inspect local rules. If authentication is rejected, revisit the username, password, and source network restrictions. If the handshake succeeds but the destination times out, check name resolution and the route from the server to the destination. This layered approach is more effective than repeatedly changing protocol types and gives your service provider a clear problem description instead of just “it doesn't work.”

06 / WireGuard: Keys, Peers, and Address Routing

A Network-Layer Tunnel

WireGuard is designed around network-layer tunneling, a compact cryptographic suite, and identifying peers by public key. Compared with a proxy type that uses a single password, it usually requires understanding the local interface address, peer identity, connection endpoint, and range of addresses allowed through the tunnel. More fields do not mean that every field authenticates the connection. Some identify peers; others describe how to route network packets, and those roles need to be understood separately.

Private Key is the private key for the current client, and Public Key represents the corresponding identity. The peer's Public Key identifies the remote peer. Putting the client's own public key in the remote public key field breaks the identity relationship between the two sides. If the configuration provides a Preshared Key, it is an additional shared key, not a replacement for the public/private key pair. Never share real keys in public screenshots, articles, or logs. Remove them before describing a problem to anyone else.

Endpoint and Interface Address Serve Different Purposes

Endpoint is the network address used to reach the remote endpoint, typically an address and port. Interface Address is assigned to the local end inside the tunnel and may include a prefix length; it is not the remote server's public address. Keep the values provided by the server when importing a configuration. Do not change them to resemble your home network. An address conflict, incorrect prefix, or local address not accepted by the server can result in a successful handshake with no working traffic.

Allowed IPs associates address prefixes with a peer and affects which destinations can be sent through that peer. It is not a list of websites the user can access or a simple remark. A full address range and a limited subnet have very different meanings. Also consider how Shadowrocket's higher-level policies send requests to this server. The tunnel's routable address range and the app's traffic rules are separate constraints; one does not automatically replace the other.

Verify Traffic After a Successful Handshake

A handshake only shows that the two sides completed the relevant key exchange. It does not prove that address assignment, forwarding, and DNS are correct. If the handshake is visible but websites fail, check the tunnel address, Allowed IPs, remote forwarding, and DNS settings. If there is no handshake at all, start with the Endpoint, public key pairing, and UDP reachability. Separating these cases helps avoid repeatedly regenerating keys when the actual problem is routing, which could create a mismatch between the client and server.

MTU limits the size of an individual packet in the tunnel. The packet size supported by the underlying network must account for tunnel overhead. If the setting is too high, small requests may work while large responses stall. Adjust it based on a reproducible issue and change only this setting at a time; no arbitrary low value is a universal optimization. If the problem occurs only on a particular network, consider differences in the underlying path instead of assuming the entire WireGuard configuration has failed.

Keepalives, Roaming, and Battery Use

WireGuard uses UDP and has a mechanism for updating a peer endpoint when the network address changes, but recovery still depends on mobile system scheduling, NAT state, and network conditions. Some configurations use Persistent Keepalive to maintain a mapping. More frequent keepalives are not always better: a short interval can increase wireless activity during standby, while a long one may not maintain a mapping required by a particular network. Keep the existing configuration's requirements and adjust only to address a specific problem.

On iOS, sustained traffic and extended standby are different workloads. For sustained traffic, focus on throughput, heat, and packet-loss recovery. During standby, check for ongoing background activity and keepalive wakeups. A simple network-layer tunnel does not necessarily use less battery in every situation. To check the fields, see WireGuard Fields Explained. If you only have a proxy password and no key or address details, you cannot use that alone to build a working WireGuard entry.

07 / Hysteria2: UDP Paths and Congestion Control

Transport Built Around QUIC

Hysteria2 builds proxy transport on QUIC, which runs over UDP and uses TLS for its security handshake. Its design considers performance under conditions such as high latency and packet loss, but it is not guaranteed to be faster on every network. If the network blocks UDP or the UDP path is particularly poor, the protocol cannot overcome the underlying reachability requirement. It may not establish a connection at all.

When considering QUIC, distinguish its multiple streams from the resources of the underlying link. Independent streams can reduce some forms of cross-stream blocking, but still share the wireless link, path capacity, and congestion state. After packet loss, data in a particular stream may still need to be recovered. “Multiplexing” does not double bandwidth or mean that requests can never affect one another. Server processing, destination response times, and network queues still shape the experience.

Keep Authentication and Certificate Settings Separate

A Hysteria2 entry must match the server's address, port, and authentication details. Enter the security-layer name and certificate verification settings according to your existing configuration. Password or its equivalent authentication field does not replace the TLS certificate. Even when the server uses a domain endpoint, check whether Server Name must match a particular value. If you connect by IP but the certificate is for a domain, the name field is especially important; do not clear it just to make all fields look consistent.

Some deployments also specify obfuscation settings. These parameters are part of the agreement between the two sides. Enable them only when the server explicitly requires them, and match the type and credentials. A random obfuscation password does not improve compatibility; it may prevent the traffic from being interpreted correctly before authentication begins. After importing a subscription, check that these additional fields are complete before concluding that the issue is network quality.

Bandwidth Settings Are Not a Speed Multiplier

Fields for upstream and downstream bandwidth provide input to the relevant transport strategies; they do not increase the connection's capacity to the number entered. A value far above actual capacity may make sending behavior unsuitable for the link, causing queues, packet loss, or disruption to other tasks on the same network. A value that is too low may actively limit throughput. Check the units as well: confusing bytes per second with bits per second can produce an order-of-magnitude error.

Not every server configuration uses client-provided bandwidth information in the same way. Understand congestion control behavior in the context of the settings supported by both sides. The safest starting point is your existing configuration and the server's documentation, not a supposed best value from someone else's device. If you adjust a value, establish a baseline on a stable network and separately observe single-task downloads, uploads, and web browsing. Do not chase a one-time peak at the expense of other requests' wait times.

How to Tell Whether It Suits a Mobile Network

Available cellular capacity and latency can vary with signal strength and cell load. A bandwidth measurement at one moment may not represent an entire session. Repeated tests in elevators, vehicles, or low-signal areas also mix radio changes into a protocol comparison. First verify the basic connection in a fixed location with a stable signal, then observe recovery during actual movement. This helps distinguish a configuration error from a temporary failure caused by network fluctuations.

High throughput, encryption processing, retransmissions, and wireless activity can all increase power use. Hysteria2 may shorten task completion time on some paths, while persistent packet loss on others may add overhead. It cannot be labeled universally as either battery-saving or battery-draining. If you have multiple compatible endpoints, record completion time, stability, and actual battery change for the same task. With only one endpoint, verify its fields first; there is no need to replace the entire configuration because of a protocol name.

08 / Choose by Use Case, Then Verify with Rules and Tests

Start with What You Have, Then Compare the Trade-Offs

The first consideration should be the endpoints the server actually provides. If your existing subscription contains only one protocol, first make sure it was imported completely, authentication is correct, and the destination is reachable. There is no need to change the type based on protocol rankings. If you have multiple working endpoints, compare them by task: frequent web requests depend on DNS and first-response time; sustained downloads depend on throughput and stability; real-time apps need UDP support and consistent latency; access to a private network depends on accurate address routing.

For endpoints that require explicit TLS and transport settings, prioritize whether the details are complete and can be checked clearly during maintenance. For a network-layer tunnel, confirm that the keys, addresses, and routing ranges are all provided. For UDP-based transport, verify that the current network allows UDP and carries it reliably. Do not choose a protocol just because it has fewer fields or a newer name. Accurately matching the service you have and being able to troubleshoot it by layer are also important parts of practical usability.

Global Routing Does Not Change the Protocol

Global Routing modes such as Config, Proxy, and Direct use the interface terms Config, Proxy, and Direct. Config uses the rules in the current configuration to choose a policy; Proxy sends matching traffic to a proxy policy; Direct uses a direct connection. Switching these modes changes routing decisions, not the server protocol. If the current request never reaches the selected server, comparing protocol speed for that request is not meaningful. Check the route first.

The snippet below illustrates rule order. Add it to the relevant rules section in your Shadowrocket configuration and make sure the proxy policy points to a working server. It is not a complete configuration and contains no server credentials. DOMAIN-SUFFIX matches the specified domain suffix first. GEOIP then handles destinations that match the relevant regional IP database, and FINAL sets the policy for remaining requests. Whether you need a regional rule depends on your own needs; do not copy it mechanically.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

Rules are usually evaluated in order, so more specific conditions should appear in the appropriate position. FINAL handles connections that remain unmatched. IP rules and domain rules use different inputs, and DNS results can affect the decision. A destination using DIRECT does not prove the selected proxy protocol is broken. A destination routed through PROXY and then failing does not prove the rule syntax is wrong. For more configuration steps, see the Settings Guide; for a first connection, see the Getting Started Guide.

Keep a Repeatable Test Record

To test, select the intended server on Home, check Global Routing, turn on the connection, and run Connectivity Test. Then visit an actual destination used by your app. The test result only covers the check it performed; it does not validate every protocol capability, destination, or routing path. Record the network type, selected entry, destination, and stage where the failure occurred. Do not share subscription links, passwords, or keys publicly; remove sensitive details before contacting your service provider as well.

If nothing connects, check in this order: address resolution, port and transport, TLS, then protocol authentication. If the connection succeeds but some destinations fail, check DNS, rule matches, UDP, and the destination service. Change only one variable at a time during performance tests; do not switch servers, change transport, and adjust routing all at once. For battery comparisons, use the same observation period and screen usage. Start after device temperature and background activity have stabilized; do not compare two periods with different workloads directly.

Finally, treat protocol selection and getting the app separately. The iPhone / iPad version costs $2.99 as a one-time App Store purchase; the Mac (Apple Silicon and Intel), Windows, Android, and Linux versions are free. For download and installation questions, see the Download Guide and FAQs. This is the Shadowrocket official site and manual; it does not provide, sell, or recommend nodes or subscriptions. To understand the interface, see the English Interface Terms Guide. To check the connection sequence, see First Connection Walkthrough, then return here to review the technical details for your protocol.