Shadowrocket Protocol GuideProtocol Types, Settings & Connection Checks

1. Choosing a Protocol: Separate Authentication, Transport and Routing

In Shadowrocket, the protocol type determines how the client exchanges data with a server. It does not determine the server's location, available bandwidth or service quality. Choose a type based on the server details you already have: use the type provided by the server, and don't expect changing the option in Add Server to turn one connection into another protocol. Get subscription links from your service provider; after importing, check the type, address and authentication details. A one-time app purchase is not a connection plan. The app and connection service are separate. For information on getting the app, see how to verify the official App Store listing.

Break a Connection into Four Layers

The first layer is identity and message format, such as a password, UUID or key, and how the server interprets a request. The second is transport, such as TCP, UDP, WebSocket or QUIC-based transport. The third is the secure session, which may use encryption built into the protocol or an outer mechanism such as TLS. The fourth is routing: whether a particular request uses PROXY or DIRECT. These layers work together, but none can replace another. Switching Global Routing to Proxy can change where traffic goes, but it cannot fix an incorrect password. Enabling TLS won't make the server accept a mismatched transport format.

A shared protocol name doesn't mean every extension is compatible. A server may require a specific transport, path, certificate name or additional setting, and the client may support only some combinations. When you see VMess or VLESS, check the outer transport too. For HTTP, confirm whether the proxy endpoint itself is protected by TLS. Available fields in the interface vary by type. Use the options shown in your current client and the server's documentation as your reference—not the position of a field in a screenshot of another configuration.

Speed, Battery Use and Stability Aren't a Single Ranking

Page load times can include DNS lookup, connection setup, authentication, first response and content transfer. Long downloads are more affected by outbound bandwidth, packet loss recovery and server load. One setup may be faster for small files without having an advantage on long downloads. Battery use on iPhone and iPad also depends on cellular signal, screen brightness, how long the radio stays active and background reconnections. Fewer layers don't automatically mean lower power use, and higher throughput doesn't necessarily mean less energy for the whole task. Compare under similar conditions.

Network changes are another variable. When a device switches from Wi-Fi to cellular, its local address and network path may change. Whether an existing session recovers depends on the transport, server behavior and the app's retry logic. Don't assume a brief pause after switching networks means the protocol has failed, and don't mask the issue by toggling several settings at once. Start with one repeatable task. Record whether the failure occurs before connection setup or during data transfer, then check the relevant layer.

This guide explains client-side protocol choices and configuration boundaries; it does not evaluate service providers. Check the App Store listing for system requirements. Protocol and field support depend on the current client. If you're unsure what an additional setting does, it's usually best to keep the imported value. Change it only after confirming which server setting it corresponds to.

2. Shadowsocks: Lightweight Proxying and Matching Encryption Methods

Shadowsocks is designed to provide a relatively lightweight encrypted proxy connection. The client sends the destination address and payload to the server, which then connects to the destination. This makes it a proxy protocol, not a network-layer tunnel that creates a full private subnet between two endpoints. Its basic settings are usually easy to identify: server address, port, encryption method and password. But fewer fields don't mean fewer checks. The encryption method is part of the protocol exchange, not a performance preference the client can choose on its own. A mismatch with the server can cause a timeout, immediate disconnect or authentication failure.

Check the Encryption Method and Password Together

Modern Shadowsocks deployments commonly use authenticated encryption, which lets the receiver decrypt data and check that it hasn't been altered. Methods may differ in key length and derivation rules; some require a correctly formatted encoded key rather than an arbitrary text password. When importing, preserve the method name and password exactly. Don't decode an encoded string before pasting it, or remove trailing characters because they look unnecessary. If a connection stops working after a subscription update, first check whether the password changed or the type was updated, then investigate the network.

To enter details manually in Add Server, select Shadowsocks first and then fill in the original information. Enter only a hostname or IP address in the address field and put the port in its own field. Don't paste a full share link as the server address. If the details include a plugin or additional encapsulation, check whether the current client offers the relevant option and whether the import included it. The same base protocol name doesn't guarantee that different plugin combinations can communicate. If you're unsure about an extra setting, refer to the existing configuration details instead of cycling randomly through options.

Test TCP and UDP Separately

Web browsing often uses TCP, but some real-time apps, voice services and other traffic use UDP. Shadowsocks can handle TCP and UDP forwarding, and server support, network reachability and client behavior may differ between the two. A page loading successfully proves only that one path works; it doesn't confirm the UDP path. Conversely, a single app failing doesn't necessarily point to a protocol issue—it may also involve DNS, routing rules or the destination service. First identify the traffic type the app uses, then check whether the relevant requests are going through the proxy.

UDP doesn't have TCP's connection semantics, and network devices may clear idle mappings more quickly. A first request failing after the app has been in the background, then succeeding on retry, can sometimes be related to an expired mapping or a changed path. Don't immediately increase keepalive frequency; that could keep the cellular radio active and use more power. First check whether the issue occurs only after a long idle period or on a particular network. If transfers are stable but requests fail after waking, investigate differently than you would for a connection that can't authenticate from the start.

Assessing Performance on Mobile Devices

Shadowsocks uses relatively lightweight basic encapsulation, which may reduce overhead from extra protocol layers. Actual speed still depends on encryption implementation, device capabilities, server egress and round-trip latency. Different algorithms can perform differently across processors. A larger number in an algorithm's name doesn't automatically mean it's more secure or faster, and you shouldn't switch to a method the server doesn't support just to chase speed. For battery tests, track how long the same task takes, how often the connection reconnects and what happens in the background—not just a momentary throughput reading.

Shadowsocks can suit users with a compatible server who want a proxy connection configured with a clear address and authentication details. If you need private subnet connectivity, identity based on keys at both ends or full network-layer routing, read the WireGuard section instead of trying to make Shadowsocks meet those needs. They solve different problems: choose based on the access model first, then consider performance. If an imported subscription entry is already working reliably, keeping its original settings is usually better than editing it just to standardize the protocol type.

3. VMess and VLESS: Separate Identity Protocols from Outer Transport

VMess and VLESS are often mentioned together because both may appear in configurations with user identity and outer transport settings, but they aren't interchangeable. VMess combines user authentication, request format and encryption mechanisms. VLESS uses a more streamlined approach to identity and request handling, and usually relies on the chosen outer security mechanism to protect transport. It isn't VMess with a different name, and it isn't automatically faster on every network. Start with the protocol offered by the server, then check the full configuration. Copying a UUID alone doesn't make a complete setup.

A UUID Is an Identity, Not a Server Address

A UUID identifies a user; a server address identifies the connection endpoint. They serve different purposes. When entering a UUID manually, preserve every character and hyphen, and check that no spaces or line breaks were copied with it. If the server has removed that user or changed its identity, or the subscription still contains an old value, the port may be reachable while authentication fails. Some older configurations include legacy compatibility settings. Keep those values only as specified by the original configuration; don't apply them based on an unrelated guide or assume every deployment requires them.

VMess authentication includes time-related checks, so a significantly incorrect device date or time can cause repeated failures. Check that automatic time is enabled before investigating other settings; this is often more useful than repeatedly changing ports. VLESS uses a different identity and outer security arrangement, so VMess troubleshooting steps don't all apply. For either protocol, distinguish between an unreachable endpoint, a failed outer session and a rejected identity. Use logs or connection records to identify the stage rather than relying only on the connection toggle's status.

WebSocket, Paths and Server Names

When the outer transport uses WebSocket, the client and server must agree on the transport type and request path. Path capitalization, a leading slash and any attached parameters can all matter. Text that looks like a note may actually be a configuration value. HTTP Host identifies the host at the request layer; the TLS server name is used during secure session handling. They may match, or differ depending on the deployment. The server address can be a third value, so don't automatically enter the connection endpoint in all three fields.

When using TLS, check that the certificate matches the expected server name. If the connection target is an IP address but the certificate is issued to a domain, enter the name specified by the server. Disabling certificate verification is not a substitute for matching the fields. If a forwarding layer sits in front of the endpoint, the request may reach that layer before being routed to the actual service. A mismatched path or Host can send a request to a responsive endpoint without reaching the intended service. That may look like a password failure, but the checks are different.

Costs and Limits of Encapsulation

An additional transport layer usually adds handshakes, headers and state management, but the impact depends on connection reuse, network latency and request size. Frequent short connections are more likely to incur setup costs; long transfers may be limited mainly by server throughput. When comparing VMess and VLESS, differences can't be attributed to the protocol alone if they use different outer transports or endpoints. Keep the server location, network, task and test time consistent, and record the transport combination—not just the protocol name.

On iOS, frequent reconnects, retries and network changes can affect battery more than a small amount of protocol overhead. If an entry shows as connected but requests repeatedly fail, check identity, time, path and TLS before looking for repeated retries. Use special flow-control or extension settings only when the current client supports them and the server details specify them. If an imported subscription entry is missing a required field, refresh the original subscription or check its source details rather than adding a similar-sounding field by hand.

4. Trojan, HTTP and SOCKS5: Endpoint Capabilities and Security Boundaries

Trojan, HTTP and SOCKS5 can all provide proxy access, but they differ in authentication, transport protection and how they represent destinations. Trojan carries proxy requests over a TLS-protected connection and commonly uses a password for authentication. HTTP proxies use familiar request and tunnel semantics, while SOCKS5 provides general-purpose proxy negotiation. The basic HTTP and SOCKS5 protocols don't automatically encrypt the connection between client and proxy endpoint. Know what the server actually offers, and don't assume that visiting a secure website protects the connection to the proxy itself.

Trojan: Check TLS Before the Password

A typical Trojan configuration includes a server, port, password and TLS settings. The TLS session is established before authentication, so a certificate problem can prevent the password from ever being checked. If the address is reachable but the handshake fails, check the system time, certificate validity, server name and server-side security settings. If the certificate and name are correct but authentication fails, check that the password is complete and current, and that it contains no unintended invisible characters. Not every failure is a wrong password, and changing routing mode won't fix a certificate error.

Some deployments combine different services on the same endpoint, making the server name and request handling especially important. A responding port only shows that a service is listening there; it doesn't prove that the responder is the intended proxy endpoint. After selecting Trojan in the client, check whether the imported details include additional transport settings and whether the current client supports that combination. Without source information, don't add quotation marks, encoding or a prefix to the password. Forms generally expect the original field value, not an entire share string with a protocol identifier.

HTTP: Tunneling and Endpoint Encryption Are Different

An HTTP proxy can forward ordinary requests or use CONNECT to establish a byte tunnel to a destination. If the destination uses TLS, its content may remain encrypted inside the tunnel. But whether negotiation details and proxy authentication are protected depends on whether TLS is used for the connection to the proxy itself. Confusing “visiting a secure website” with “connecting securely to the proxy endpoint” can lead to a mistaken view of what authentication data is exposed. If the details specify a TLS-protected proxy endpoint, configure the correct type and security settings; don't just change the port.

HTTP proxies can suit environments with a clearly defined access policy, but don't assume they support every type of UDP traffic. If a website works but a real-time app doesn't, the endpoint may not support that traffic; the client rules may be fine. Usernames and passwords may also be subject to access scope, concurrency or expiry limits. For rejected authentication, check the account status and original details. If only some destinations are rejected, distinguish endpoint policy from the destination's response. Repeatedly refreshing a subscription is no substitute for finding the cause.

SOCKS5: General-Purpose Negotiation Isn't Built-In Encryption

SOCKS5 can specify a destination address and port, and defines authentication negotiation and UDP forwarding. Confirm separately whether the server enables authentication and supports UDP. Basic username/password authentication does not encrypt content, so the connection needs protection appropriate to your use case. Whether the proxy receives a domain name or an IP address also affects where DNS resolution happens. Seeing SOCKS5 in the type field doesn't prove that every domain lookup happens remotely; check the client's resolution strategy, routing requirements and actual connection records.

For these three endpoint types, choose based on the actual capabilities of your existing service, not a vague speed comparison. Trojan's secure session has setup overhead; HTTP tunneling may be limited by endpoint policy; SOCKS5 UDP can be affected by network devices. On mobile, test short requests, sustained transfers and recovery after idle time separately. If the access scope or security requirements aren't clear, ask your service provider what the fields mean. Don't probe by disabling verification, leaving a password blank or switching to a similar type.

5. WireGuard: Keys, Tunnel Addresses and Network-Layer Routing

WireGuard is centered on network-layer tunneling and peer identity, with a design that emphasizes a compact protocol and a defined set of cryptographic algorithms. Unlike a proxy model that handles requests to individual destinations, it carries network packets through a tunnel. Its configuration therefore needs to describe the local tunnel identity, peer endpoint and allowed address ranges. A server hostname and password aren't enough to configure WireGuard, and passwords from other protocols don't belong in key fields. Before using it, get complete details for the current device and confirm that the server has the matching public key registered.

The Roles of Private Key and Public Key

The Private Key is local identity material and must be kept secret. The Public Key lets the peer identify that identity. The peer's public key in the client configuration should come from the server details, not from the local device. The server also needs the client's public key. If the two configurations don't match, UDP packets may reach the endpoint without establishing the intended secure communication. If the details include a preshared key, it's an additional shared secret; it doesn't replace either side's key pair. Don't paste the same string into multiple fields just to make them look consistent.

When changing devices, distinguish between restoring a configuration and reusing the same identity on multiple devices at once. Two devices sharing an identity and address can make the endpoint observed by the server change repeatedly, causing instability or sending traffic to the other device. Whether reuse is allowed depends on the server deployment; being able to import a file doesn't guarantee concurrent use. When troubleshooting, note how many devices use the identity and follow the service's instructions for assigning separate details. This is usually more useful than repeatedly switching servers in the client.

Endpoint, Address and Allowed IPs

Endpoint is the peer address and port reachable over the current network. Address is the local address inside the tunnel. They aren't interchangeable. In WireGuard's protocol model, Allowed IPs associates address selection and inbound validation with a peer. In a client integration, it also needs to be understood alongside the app's routing behavior. If a subnet isn't covered correctly, the tunnel handshake may succeed while the destination remains unreachable. Conversely, a range that's too broad may route traffic that should stay local along an inappropriate path.

Access to a private network also depends on the return path. Packets reaching the peer don't mean devices behind it know how to respond to the client's tunnel address; server forwarding, return routing and access policies can all affect the result. If you can reach the peer itself but not the subnet behind it, focus on the server-side network configuration rather than generating new client keys. DNS is a separate concern: private hostnames may need a specific resolver, but choosing a resolver doesn't make the resulting address reachable by itself.

UDP, MTU and Keepalive in Practice

WireGuard uses UDP, so the current network must allow the relevant UDP traffic. If the path's effective MTU is too low, small requests may work while large responses or some services stall because encapsulation adds packet overhead. Check deployment guidance and path conditions before making a justified adjustment; don't treat one fixed value as the answer for every network. After each change, test with the same large file or fixed request and keep the original value so you can confirm whether the change actually helped.

Persistent Keepalive can maintain a network mapping when needed; more frequent keepalives don't automatically make a connection more stable. On cellular networks, periodic traffic can keep the radio active longer. Without a need to maintain a mapping, excessive keepalives may only increase background activity. WireGuard's compact design can limit protocol overhead, but battery use still depends on traffic, signal and reconnections. It can suit use cases with complete peer details and clear network-layer address requirements—not simply the pursuit of lower battery use based on a protocol name.

6. Hysteria2: QUIC, Congestion Control and Bandwidth Expectations

Hysteria2 is designed for proxy transport based on QUIC, with a focus on maintaining effective data transfer over paths with packet loss or high round-trip latency. QUIC runs over UDP and provides secure sessions and reliable transport, so it isn't simply raw UDP forwarding and doesn't eliminate congestion control. The first requirement is compatible server details and a network that can carry the necessary UDP traffic. Similar names across protocol generations don't guarantee compatibility, so preserve the exact type when importing.

Check UDP and TLS Requirements First

The endpoint, port, authentication details and TLS server name must all match. A network that allows web browsing over TCP may not allow UDP traffic to the same endpoint; some networks restrict UDP or handle sustained traffic differently. If every request times out while establishing a session, check UDP reachability and whether the server is listening before changing bandwidth settings. If the session reports a certificate problem, check the system time, server name and trust chain. A higher speed setting can't bypass a failed secure session.

Server details may include additional transport settings. Confirm that the current client supports them and that they were imported correctly. Authentication values are part of the access credentials; don't substitute a website password or a password from another protocol. If the deployment changes ports, check the full server instructions against the client’s capabilities. One port connecting occasionally doesn't prove the configuration is correct. If details are incomplete, stop guessing and get the exact fields before testing performance; otherwise each failure has too many unknown causes.

A Bandwidth Setting Doesn't Guarantee Actual Speed

Some configurations use expected upload and download bandwidth values. These may influence transport behavior or congestion control, but entering a number in the client can't create more network capacity. Setting expectations well above the available bandwidth can build up queues, increase packet loss and crowd out other traffic on the same network. Setting them too low may limit available throughput. Whether to enter these values, what they mean and how they work with server settings depend on the current implementation and service guidance—not on a universal fixed value.

Direction matters too: sending data from the device and receiving data on it are different. Don't copy the same number into both fields just because a speed test highlights the download result. Cellular capacity varies with location, signal and time of day, so an expectation that works in a lab may not suit a moving device. Keep a conservative baseline and change settings gradually. Track task completion time and the effect on other apps; higher throughput with noticeably worse responsiveness isn't necessarily an overall improvement.

Packet-Loss Recovery: Benefits and Resource Costs

QUIC can multiplex several data streams over one connection, avoiding some delivery limitations of a traditional ordered byte stream shared by all traffic. But all streams still use the same underlying path and congestion resources. A lost packet still requires recovery of the affected data; the practical benefit depends on the task and path conditions. QUIC may outperform other transports on some networks, but show little difference on a stable, low-latency path. Treating one speed test as a ranking for every use case ignores two major variables: server configuration and network conditions.

On iPhone and iPad, user-space protocol processing, encryption, sustained high throughput and packet-loss recovery all use device resources. A task that finishes sooner may reduce the time the network stays active, but continuously pushing the connection to high load can also increase heat and battery use. Assess stability, completion time, background recovery and device behavior together. A connection that waits a long time and repeatedly retries isn't a useful battery test; fix reachability first. Choose a protocol for real-world tasks, not to maximize a single setting.

7. Check Settings: Test Protocol Connections and Routing Separately

Protocol settings control the connection to the server; Global Routing determines how traffic uses that connection. Test them separately to avoid mistaking a routing issue for a protocol issue. First, confirm the selected server in Home, then check Global Routing. Config applies configuration rules; Proxy routes traffic through the selected proxy for diagnostic purposes; Direct connects without the proxy. These are routing choices and don't change server authentication or transport capabilities. For the main workflow, see the setup guide. For an explanation of the three modes, see Global Routing: Config, Proxy and Direct.

Check Addresses, Names and Authentication in Order

A server address can be a hostname or IP address. If you use a hostname, the endpoint itself must resolve; an incorrect resolution happens before protocol authentication. The TLS server name is used in secure session handling and shouldn't be confused with the destination website's domain. The port must match the one the service listens on; changing it to a common port won't make the server provide another protocol. Usernames, passwords, UUIDs and keys belong to different authentication systems. Empty values, encoding changes and leading or trailing spaces can all change their meaning, so check them against the original details rather than reinterpreting them.

Don't paste a full share link into a single settings field or use a subscription link as a server address. A subscription is an entry point for a collection of configurations; individual entries may contain protocol and authentication details. After a subscription update, older entries may be replaced, renamed or removed, and manual changes may be overwritten on refresh. To test a change over time, make a separate copy with a clear name, and don't include a password in the name. For the different import options, see how to import a subscription.

Rules decide where traffic goes; they don't fix the server

The following Shadowrocket .conf rule snippet illustrates matching order. It contains no server definition and isn't a complete file to replace your existing configuration. The domain rule checks the specified suffix first, the local subnet rule handles the relevant addresses, and FINAL provides a fallback for remaining requests. Before adding it to an existing configuration, understand its current rule structure and default policy to avoid overriding private network routing. The reserved example domain is for syntax demonstration only and does not represent a connection service.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

Rules are generally matched in order. A broad condition placed too early can take precedence over a more specific one later. DOMAIN-SUFFIX matches domain suffixes; IP-CIDR matches address ranges. They rely on different information. Some address checks may involve DNS, so DNS results can affect subsequent behavior; a successful DNS lookup alone doesn't prove that the proxy can reach the destination. To troubleshoot, first use a clear domain rule to verify routing, then check the actual destination address in the connection record. Don't add several overlapping test rules at once.

Use a Controlled Test to Separate Rules from Protocols

If the same server completes a fixed test in Proxy mode but fails in Config, check rule matching, policy references and DNS before changing the protocol. If both modes fail, continue with the server settings and endpoint path. Direct can confirm basic connectivity on the current network, but a successful direct connection doesn't prove the proxy server is reachable. When testing is done, restore the routing mode you normally need. Otherwise, temporary diagnostic settings may continue changing where all traffic goes and make later observations differ from your everyday configuration.

For IPv6, check that destination resolution, rules and server capabilities are consistent. Rules that handle only IPv4 may not cover IPv6 requests. A domain resolving to different addresses on different networks can also create seemingly random differences. Don't rewrite all DNS settings just because some requests fail. First record the address family, matched policy and time of failure, then test one factor at a time. See the quick reference for common terms, and don't treat concepts from different layers as the same setting.

8. Choose for Your Use Case: Evaluate with Repeatable Tests

The first priority when choosing a protocol is compatibility with your existing server. Next, consider the task and network conditions. If your current setup is stable, there's no need to switch just to chase a protocol name. For everyday browsing and messaging, focus on first response, background recovery and connection success rate. Sustained transfers depend more on throughput and long-term stability. Private network access requires correct address relationships and a return path; UDP-based services require a working UDP path end to end. Comparing options is useful only when the server genuinely offers multiple compatible choices.

Keep a Repeatable Test Log

Keep the device, network, destination and test task consistent. Turn off other experimental settings that could affect results, and keep a copy of the current configuration. Record the protocol and outer transport, Global Routing mode, whether the network was just changed and where any failure occurred. For web tests, use the same destination and similar content. For sustained transfers, use the same file and duration, and account for caching. Don't compare the setup time of a new connection with a request on a reused session, or attribute all differences in server load at different times to the protocol.

Connectivity Test can help check whether the selected entry is reachable or how a test request performs, but one successful result doesn't prove that every service works, and one number isn't a measure of total throughput. Combine it with access to the actual destination and connection records to distinguish endpoint reachability, successful authentication, request transmission and completed response. For the first connection, see the first connection checklist. If the connection toggle is on but websites won't load, don't update the subscription, change DNS and switch protocols all at once; you won't know which change mattered.

Narrow Down the Cause by Failure Stage

1. Before reaching the endpoint: Check the local network, server hostname resolution, address and port. Confirm that the selected entry is the one you're testing.
2. Session setup: Check the protocol type, TCP or UDP requirements, TLS name, system time and certificate issues.
3. Authentication: Check the password, UUID, keys and server-side registration. Confirm that the subscription doesn't contain outdated details.
4. Request: Check Global Routing, rule matching, destination resolution, UDP support and address family.
5. Sustained transfer: Check packet loss, effective MTU, server load, bandwidth expectations and changes to idle mappings.

The goal isn't to look for one fixed error message, but to put the evidence in the right place. Checking a password won't help if the endpoint hasn't responded at all. If the handshake completes but only one subnet fails, investigate routing and the return path. If every destination starts loading but stalls on a larger response, consider the path and packet size. When logs show only a generic timeout, run a controlled comparison—for example, test another confirmed working entry on the same network and in the same routing mode—instead of concluding that the protocol is unsuitable.

Include Background Use and Network Changes in Battery Tests

Measure battery use over the same kind of task and a similar period of use, keeping screen brightness, signal, background apps and test duration as consistent as possible. Record heat, frequent reconnects, recovery after idle time and behavior when switching from Wi-Fi to cellular. A small change in the battery percentage over a short period is too imprecise to support a claim that a protocol saves a fixed amount of power. If the connection keeps failing and retrying, fix the cause before comparing. Include idle time after a task finishes early to get a result closer to everyday use.

For long-running background connections, configure keepalives and On Demand based on actual needs rather than enabling everything. Keepalives may maintain a mapping, but they can also increase network activity. On Demand triggers connections under specified conditions; it doesn't fix authentication or rule errors. If you have to reconnect manually after every network change, check the system trigger conditions, transport recovery and server status separately. One network-switch test is only a clue; repeat it under the same conditions and keep connection records from before and after recovery.

State the Conditions Behind Your Conclusion

A useful conclusion describes which combination is more stable on a particular device, network, task and server configuration—not which protocol is always fastest. For everyday use, prioritize entries with clear settings, reliable recovery and straightforward maintenance. Choose a different type only when you need its specific network capabilities. Keep a confirmed working baseline, update your subscription through its original source, and avoid maintaining multiple copies with unclear purposes. For more help, see the FAQ or step-by-step guide to fixing a connection with no internet access.