Shadowrocket
Rules & Configuration Reference

01 / Files and scope

Configuration structure and when it applies

First, distinguish server details from configuration files

Server details determine which existing service a request uses to connect. A configuration file determines which handling policy applies when a request meets certain conditions. They are related, but they are not interchangeable. After importing a subscription, entries may appear in the SERVER list on Home, but that does not mean a suitable routing configuration is selected in Config. Likewise, a rule file containing PROXY does not fill in a server address, port, or authentication details. Before troubleshooting a connection, check the active server and selected configuration separately. A refreshed list does not necessarily mean the rules were updated.

.conf is a file format for organizing configuration text. Start by locating the section headers in square brackets, then inspect the contents of each section. General typically contains global parameters, Rule contains ordered matching rules, Host contains hostname mappings, and URL Rewrite contains rewrite entries. Section headers are not ordinary comments: missing brackets, placing rules in the wrong section, or deleting line breaks while editing can change how the file is parsed. Check not only that a rule is spelled correctly, but also that it is in the right section.

Identify each section’s syntax with a minimal example

[General]
bypass-system = true

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

[Host]
lab.example.com = 192.168.1.20

This example shows three different structures. General and Host use equals signs for parameters or mappings; Rule uses commas to separate fields. For a domain suffix rule, the second field is the match value and the third is the policy. FINAL has no separate match value, so the policy follows it directly. The private address is shown only to illustrate Host syntax and is useful only if that host exists on your network. This is not a recommended configuration and does not include everything needed to connect to a service.

A common mistake is to mix syntax between sections—for example, replacing the comma after DOMAIN-SUFFIX with an equals sign, or writing a Host mapping as a Rule. When copying code, check for full-width punctuation, quotes copied around domain names, and rich-text formatting in the file. After saving, check whether the app reports a parsing issue. If it identifies a line number, inspect that line and the one before it: a missing line break or section boundary may cause an error to surface on the next line.

Save, select, and apply: three separate checks

After editing, save the configuration, return to Config and confirm the edited file is selected, then check that Global Routing on Home is set to Config. Changes to an unselected file will not affect the current connection. Likewise, when Global Routing is set to Proxy or Direct, observed traffic does not verify Rule order. App navigation may change, so follow the current interface; always track file contents, selected file, and active routing mode separately.

Manage remote configurations and local edits separately. If a file is refreshed from a remote URL, locally added rules may be overwritten. To keep changes, create a separate copy using the file-management options available in the app, edit that copy, and retain the original for rollback. Avoid changing several sections at once in your only working configuration. Test one domain rule first, then add others; if something breaks, it will be easier to tell whether the cause was the content, the selected file, or an update that replaced your edits.

To learn how to read file sections, compare each one with the .conf structure guide. Keep the full context of your current file as you read the following chapters: a valid line shows only that the line follows a particular syntax, not that the entire configuration suits your network and needs.

02 / Global parameters and hostname mappings

General and Host

General is not a substitute for Rule

Parameters in General affect the configuration’s overall handling environment; they are not a list of per-site routing rules. For example, bypass-system = true relates to bypassing system traffic; it does not mean “send every site DIRECT.” Settings of this kind may keep some traffic out of ordinary rule matching. When investigating a request, first check whether it falls within the traffic the configuration can observe and handle. The presence of FINAL alone does not prove that every connection on the device passes through that rule.

Before changing a global parameter, define the problem you are trying to solve: is domain resolution failing, is local network access behaving unexpectedly, or is a certain request missing from the logs? Only then can you judge whether the parameter is relevant. Replacing the entire General section with a snippet found online may alter DNS, bypass behavior, and connections all at once. Even if access returns, you will not know which change helped. Keep the original values, change one parameter at a time, and compare the same request before and after.

[General]
bypass-system = true

This example shows only how to write a Boolean parameter; keep the parameter name, equals sign, and value in their original English form. Do not infer additional parameters from the name or copy keys directly from another configuration format into .conf. Use the app’s current support and guidance to determine which parameters it recognizes and how they work. If a key is unfamiliar, check the existing configuration notes and in-app messages rather than trying variations of its spelling. A file saving successfully does not, by itself, prove that every parameter is taking effect as intended.

Host changes mappings, not policies

Host maps a specified domain to an address. It answers “which address does this name resolve to?”; Rule answers “which policy should handle this request?” Adding a domain to Host does not make it DIRECT. If a domain rule matches first and selects PROXY, the request is handled according to that match. Once a Host mapping takes effect, later checks involving the destination address may use a different address. When analyzing this setup, record the hostname, resolved address, and policy separately.

[Host]
lab.example.com = 192.168.1.20

[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY

The mapping and domain rule appear together here to show how they differ. lab.example.com is an example hostname, and 192.168.1.20 is a private address; replace it with a host that actually exists on your own network. Even if a rule selects DIRECT, the device still needs network access to that private address. If it is not on the relevant local network, or the target device is not serving the required service, a correct rule match will not make the connection succeed. Routing decisions and destination reachability are separate outcomes.

Check the limits of DNS, caching, and connection reuse

Host does not automatically change application-layer identity. When accessing an HTTPS domain, the server certificate should still match the name being accessed. Mapping the name to an address that does not serve that domain may cause a certificate or handshake error; adding a DIRECT rule usually will not fix it. First check that the destination address is correct, that the service is listening on the relevant port, and that the server serves the requested domain. Do not mask a mismatch between the hostname and service by relaxing unrelated settings.

After changing a hostname mapping, an old DNS cache entry or existing connection may affect what you see. Close the target app’s relevant sessions, then make a new request. If needed, use tools available in the app to check the DNS result, and distinguish new requests from existing connections. Record the test domain, expected address, actual address, and matched policy. “The page won’t load” is not enough to tell whether the mapping failed, the service is unreachable, or the request was never re-established. Keeping test conditions consistent is more useful than flipping several switches.

Finally, check for duplicate Host entries, broad domain rules, and address rules that refer to the same target. Do not rely on the order of duplicate mappings to express intent; combine them into one clear mapping where possible. Addresses for public websites can change as services are deployed, so users must maintain any fixed mapping themselves. For services on your own local network, confirm that the host address is stable. Rule maintenance is about more than valid syntax: the names in the configuration must continue to match the actual network.

03 / Domain matching

DOMAIN and domain rules

Choose a scope by exact name, suffix, or keyword

Domain rules are for routing requests with known hostnames. DOMAIN matches one complete domain, DOMAIN-SUFFIX matches that domain and its subdomains, and DOMAIN-KEYWORD checks whether the hostname contains specified text. None of these matches a URL path: slashes, query parameters, and page fragments after the domain are not match values. To handle only api.example.com, do not enter a full address including https://, and do not expect a domain rule to distinguish between two pages on the same host.

Choose the narrowest scope that accurately describes what you need. Use DOMAIN for one exact host, DOMAIN-SUFFIX for a group of subdomains that share a policy, and DOMAIN-KEYWORD only when you need to match text across different domain suffixes. A keyword does not inherently identify an organization or service; another hostname containing the same text may also match. Short, common keywords can easily catch requests you did not intend to handle, and these false matches usually do not produce a syntax error.

Use specific exceptions before broader rules

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
FINAL,DIRECT

In this teaching example, api.example.com matches the exact rule first and selects DIRECT. www.example.com misses the first rule but matches the suffix rule and selects PROXY. Other names containing the text example but not belonging to example.com may then match the keyword rule and be rejected. The app does not automatically rank the three rule types by specificity; the first match ends the check. If the keyword rule comes first, the next two rules cannot provide exceptions for requests containing the same text.

For DOMAIN-SUFFIX, the value is usually example.com. No leading asterisk is needed, and wildcard syntax should not be mixed with this rule type. The suffix match respects domain-label boundaries, so notexample.com should not count as a subdomain of example.com just because its ending looks similar. For names with special characters, internationalized domains, or app-specific conversions, check the actual hostname shown in request logs and write the rule for that value. Do not infer it only from how the address looks in a browser.

The request hostname may differ from the one in the address bar

A page usually makes multiple requests. The main document may use one domain, while images, scripts, sign-in, and API calls use others. If some page content still fails after adding a rule for the address-bar domain, that does not necessarily mean the rule is broken; check the hostname used by the failed request. The same applies to apps: an app’s name does not reveal all the domains its services use. This guide does not provide a service-domain list; use your own request logs.

If a connection has only a destination IP and no hostname available to the rules, a domain rule cannot infer the missing name. Other requests may use caching, in-app resolution, or a different connection method, so the hostname in the log may not be what you expected. First check whether the record includes a domain, then decide whether a domain rule should apply. “DOMAIN did not match” does not automatically mean the client ignored the rule; the request may not have entered matching with the hostname you specified.

Test a domain rule against at least three cases: a hostname that should match, another subdomain in the same group, and a similar hostname that should remain unaffected. Change only one rule type at a time and check whether the matched rule and policy change. For more on the scope of each rule type, see rule syntax and matching scope. Testing boundary cases is more effective at preventing future false matches than checking only whether one webpage loads.

04 / Addresses, regions, and other conditions

IP-CIDR, GEOIP, and other rules

IP-CIDR matches address ranges, not website names

IP-CIDR takes an IPv4 address and prefix length as its match value. 192.168.0.0/16 represents a range of private addresses, not only the host 192.168.0.0. The longer the prefix, the smaller the range it generally covers. Before writing a rule, identify the actual network range you need; do not keep expanding it for convenience. A website resolving to an address once does not mean its entire range should use the same policy. On shared infrastructure in particular, the same range may host unrelated services.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXY

Use IP-CIDR6 for IPv6 address ranges. The example fc00::/7 is a local IPv6 address range; putting an IPv6 address in IP-CIDR will not produce the same result. A DIRECT rule for a private or local address determines the connection method; it does not create a route to that network or change access permissions on the target device. If the device is off that network, the address conflicts, or the service is not listening, the connection may still fail after matching DIRECT. Check the network and service themselves.

The point of no-resolve is to avoid triggering an additional domain lookup for this address rule. Requests already targeting an IP can still be checked against an available address. For a request with only a domain and no usable address, do not expect a no-resolve rule to identify it reliably. This is not a global switch that stops the client from resolving names, nor does it declare that a domain should always bypass DNS. Check both whether the request already has an address and whether a preceding domain rule handled it.

GEOIP reflects address data, not service ownership

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

GEOIP checks a destination address against regional data. GEOIP,CN,DIRECT selects DIRECT for a destination address that matches the region code CN; it does not classify traffic by registered owner or the user’s location. A domain may resolve to addresses in multiple regions, and address databases may not reflect the actual deployment. For important domains that need a consistent policy, add a specific rule before GEOIP instead of treating regional matching as an exact service directory.

If the same domain gets different policies at different times, first check whether its resolved address changed, then check the position of the regional rule. Do not assume GEOIP changed the order without looking at the logs. Also distinguish the region of the destination address from the region of the proxy exit; they are different fields. The object used for rule matching is not interchangeable with the exit behavior observed afterward. Address troubleshooting should record the test domain, address, and matched rule, since the next request may reach a different destination.

When to use USER-AGENT and FINAL

[Rule]
USER-AGENT,ExampleApp*,PROXY
FINAL,DIRECT

USER-AGENT matches information available in the User-Agent field. ExampleApp* is a teaching pattern, not a list of real apps, and it does not identify processes by the app names on your device. Relevant fields may not always be visible in encrypted requests, so this rule cannot reliably classify all traffic from a particular app. Do not enable unfamiliar certificate or decryption settings just to make the example match. Prefer domain or address conditions that you can verify from the request information already available.

FINAL is the fallback for requests not matched earlier; it does not need a domain or address value. Put it last in Rule to define how unmatched requests are handled. If FINAL appears in the middle, ordinary rules after it cannot handle the remaining requests. In a long file, search for FINAL first, confirm there is only one and that its position is clear, then review the specific rules above it. USER-AGENT, regional, and address rules rely on different available information. Determine what the request actually provides before adding more conditions.

05 / Policy outcomes and global routing

Policies and Global Routing

PROXY, DIRECT, and REJECT do different things

The first part of a rule determines whether it matches; the policy field determines what happens after a match. PROXY uses the current proxy selection, DIRECT connects to the destination directly, and REJECT denies the request. A policy name is neither a domain nor a server address; replacing PROXY with an arbitrary label will not make the app understand it. If the existing configuration uses named policy groups, confirm that the referenced group exists and how it is selected before using its name. The examples here use basic policies to avoid group names that may not be defined.

Matching PROXY does not guarantee that a request will succeed. Invalid server details, failed authentication, network restrictions, or a problem with the destination service can all occur after rule evaluation. DIRECT is not an instruction to “make the connection work”; it changes only the connection path. Troubleshoot these two stages separately: first check which policy matched, then investigate why the connection failed under that policy. Judging rule matching only by whether a page loads can make a transport problem look like a syntax error.

Global Routing determines whether requests follow the configuration

Global Routing has three modes: Config, Proxy, and Direct. These interface labels are related to the uppercase policy names in Rule, but they operate at a different level. Config handles requests using the selected configuration; Proxy and Direct let you observe behavior in those global modes. When testing a DOMAIN or IP-CIDR rule, switch back to Config first. Otherwise, even a correct file may not be handling traffic according to its Rule section.

Changing modes is a comparison test, not a long-term fix. If a request succeeds in Proxy but fails in Config, Config may have selected DIRECT, matched REJECT, or may be using a different file than expected. Check the request record to see what actually happened, then adjust the relevant rule. Restore the intended mode after testing so that later results are not interpreted using conditions that have changed.

Keep exceptions and a rollback path when using REJECT

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

This example shows different handling within the same suffix; it does not describe the real services behind these names. api.example.com is assigned PROXY first, metrics.example.com is rejected separately, and the remaining example.com subdomains use DIRECT. If the suffix rule is moved to the top, the two specific exceptions will not work as intended. Review policy design and rule order together; checking only that the final policy field is spelled correctly is not enough.

When using REJECT, consider how the request relates to the rest of the service. A request that looks like an auxiliary feature may be involved in sign-in, resource checks, or session renewal. If only part of a feature stops working, temporarily remove that one rejection rule and make a new request; do not delete the entire Rule section at once. Once you confirm the cause, narrow the match or add a specific exception before it. For how Global Routing relates to Home, see the first-launch and Home guide. Server availability still needs to be checked separately.

06 / Order and conflicts

Matching order and priority

The first matching rule determines the result

Rules in the Rule section are checked in order. Once a rule matches, its policy applies and the client does not keep looking for a later condition that “seems more specific.” Priority comes from placement, not the rule name: DOMAIN is not automatically above DOMAIN-SUFFIX, and IP-CIDR is not inherently below GEOIP. A clear structure is specific exceptions first, broader scopes next, and FINAL last, so the reading order reflects the evaluation order.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

For api.example.com, the first rule selects DIRECT; a later match for the example.com suffix cannot change that result. For www.example.com, the first rule does not match, so the second rule matches and ends the check. A directly accessed private address can proceed to IP-CIDR if earlier domain conditions did not apply or match. Only requests that matched nothing earlier reach GEOIP or FINAL. When tracing rules, note what information is available at each step instead of assuming every request has both a complete domain and an address.

Overlapping rules are not always a problem; explain when one masks another

An exact domain rule and a suffix rule can intentionally cover the same request to create an exception. Identical conditions that point to different policies usually need to be consolidated or explained. A later duplicate condition does not give the same request a second choice. When reviewing a large configuration, look first for exact duplicates, then for nested scopes, and finally for overlaps between keywords and suffixes. Rule count alone does not show how comprehensive a configuration is: duplicates increase maintenance work without necessarily changing behavior.

If moving a rule from the bottom to the top fixes the issue, find out which earlier rule had been masking it. Simply putting every new rule at the top leads to a growing pile of conflicting exceptions. Instead, identify the earliest broad rule that matches and place the necessary exception before it, while keeping related rules clearly grouped. Adding opposite policies for the same domain makes it harder for anyone maintaining the file later to tell which behavior was intended.

Use a request checklist to verify the effect of moving rules

Before editing, make a short expected-results table with at least three columns: target, expected policy, and expected matching condition. Include a specific exception, a general subdomain, a private address, and a fallback target. After moving a rule, retest the other cases as well as the one that prompted the change. This can reveal when fixing one exception has broken an entire suffix scope. Choose test targets from your own use case; whether an example domain in this guide is reachable says nothing about your configuration.

Address rules follow the same ordering principle. For example, if a smaller range should use PROXY while its larger containing range uses DIRECT, put the smaller range first. If GEOIP handles an address earlier, a later address exception may never run. “Specific first” is a convention expressed by the order you write; the app does not automatically sort all rules by prefix length at runtime. Do not apply matching assumptions from network routing tables directly to the Rule list.

If the configuration includes remote rule references or other extensions, check where they fall in the full evaluation chain. Reading only a few hand-written lines does not prove that no broader condition appears earlier. If a match is hard to explain, inspect the complete file from the start of Rule in its actual order. If needed, make a minimal test copy and add entries one at a time. Simplify to isolate the cause, then restore any sections the original configuration needs; do not replace a complete setup with an over-trimmed file long-term.

07 / URL Rewrite and combined examples

URL Rewrite and common patterns

Rewriting an address does not select a proxy policy

URL Rewrite processes request addresses according to a pattern. This is different from selecting PROXY, DIRECT, or REJECT in Rule. Domain routing controls the connection path; rewrite entries may change the address a request targets or return a redirect. Do not add a rewrite rule to send a domain through a proxy, and do not paste an ordinary domain rule into URL Rewrite. Express routing needs in Rule; use the rewrite section only when you actually need to change address behavior.

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

This example has a matching pattern, replacement address, and redirect status code. It demonstrates a limited HTTP-to-HTTPS redirect. The dots in the pattern are escaped with backslashes, the leading ^ anchors the match at the start of the address, and the slash after the domain helps define the host boundary. Do not assume this short example preserves every original path and query parameter as intended. If your use case requires that, design the capture and replacement explicitly, then verify each result.

For HTTPS requests, path information in the address may not always be readable in the same way. Ordinary domain routing does not require the full URL to be visible, but path-level rewriting does require access to the relevant request information. A domain rule matching successfully does not prove that a rewrite pattern can run. Do not add certificate or decryption settings just to test an example. First confirm the request type and what the app can observe; if that is unclear, keeping the original request behavior is easier to troubleshoot.

Break combined rule logic into independently testable parts

[Rule]
DOMAIN,lab.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

[Host]
lab.example.com = 192.168.1.20

This example combines a local hostname mapping, a single-domain rejection, proxy routing for a suffix, and a direct rule for a private address. Read it in order: the two specific domain exceptions, the suffix scope, then the address rule and fallback. The Host mapping points lab.example.com to the example private address, while the preceding DOMAIN rule explicitly selects DIRECT. blocked.example.com is rejected first and is not overridden by the later suffix PROXY rule. No rewrite is included so each part can be checked independently with fewer variables.

When applying these ideas, copy your existing configuration first and add only the one rule you need. If one API endpoint needs a different policy, start with an exact DOMAIN rule; do not introduce Host, GEOIP, and URL Rewrite at the same time. Verify the exact match before considering whether to broaden it to DOMAIN-SUFFIX. Configuration complexity should reflect real requirements, not how many keywords an example demonstrates. Every additional section adds another handling step to explain and test.

Avoid loops, overly broad patterns, and mixing up subscriptions with config URLs

When testing redirects, check the final address and number of redirects. A loop may occur if the new address matches the original pattern again, or if the destination sends the request back to the original address. Start with one controlled path and observe the response before broadening the match. Dots, question marks, and parentheses have special meanings in regular expressions; do not use an ordinary URL as a pattern without checking it. Even a syntactically valid pattern may affect requests it was not meant to change, causing problems with sign-in or resource paths.

Do not confuse a server subscription URL with a configuration-file URL. A subscription you already have may import server entries without returning .conf text. A configuration URL should return content the app can recognize as a configuration. The example https://example.com/sub?token=xxxx is an obvious dummy value, not a working service. If importing an uncertain URL into Config causes a parsing error, first check the content type, account status, and purpose of the address. Adding Rule keywords will not fix a response that is not a configuration file.

When sharing a configuration for review, keep only the rules and sections needed to reproduce the issue, and remove personal subscription URLs, authentication details, and other sensitive information. Explain which request should use which policy instead of sending a whole file and asking others to guess. For common interface terms and policy names, see the quick reference. The goal of a combined configuration is to make every handling step explainable, not to make one file cover every possible network adjustment.

08 / Test and maintain

Verification, maintenance, and troubleshooting

Run a test in a consistent order

A useful test needs consistent inputs and conditions. Record the current network, Global Routing mode, selected configuration, and proxy selection. Then note the full hostname to test and the expected policy. After saving a change, return to Config to confirm the file, switch Global Routing to Config, and make a new request. Do not update a subscription, change servers, or switch networks during the test; otherwise, you cannot tie success or failure to one variable. Reproducibility matters more than tapping through a series of controls.

In the request log or diagnostic view available in the app, check the destination domain, destination address, matched rule, and policy; the exact fields depend on the current interface. Some requests may not provide all of this information, so record missing details accurately. Connectivity Test can help show connection behavior under its test conditions, but it does not replace verifying a real request against your rules. A successful test shows only what happened for that target under those conditions; it does not guarantee that every site or app request follows the same path.

1. Confirm the file is saved and selected in Config.
2. Confirm Global Routing is set to Config, then check the current proxy selection.
3. Close the old session and make one clearly identifiable new request.
4. Check the matched condition and actual policy, not just whether the page loads.
5. Retest exceptions, broader scopes, and fallback targets to confirm the boundaries.

Separate DNS, matching, and connection issues by symptom

If the configuration cannot be read, start with its text structure: check section headers, English punctuation, field counts, and policy names. A DOMAIN rule usually has three fields: type, value, and policy. FINAL is followed directly by its policy; do not add a domain just to fill another field. Check whether comments or other text slipped in while copying code, especially page titles, line numbers, and automatic line breaks. Once the app recognizes the file, investigate how it handles requests. Do not troubleshoot network behavior before parsing is complete.

If the file is readable but the wrong rule matches, check in order: whether the intended file is selected, whether Global Routing is set to Config, whether the actual request hostname matches the rule, whether an earlier broader rule takes precedence, and whether FINAL appears too soon. If a domain rule cannot use a hostname, check whether the request provides only a destination address. If an address rule uses no-resolve, check whether an address is already available. Look for evidence at each step rather than calling every missing match a “rule failure.”

If the expected rule matches but the connection fails, troubleshoot the connection itself: for PROXY, check your existing server details and authentication; for DIRECT, check the local network and destination service; for REJECT, confirm that the request should be blocked. DNS failures, connection timeouts, and certificate errors occur at different stages and should not all be addressed by changing the same rule. You can temporarily compare Proxy and Direct for the same target, but restore the original mode afterward and fix the actual issue in Rule.

Keep maintenance notes that support rollback

For each configuration change, keep the before-and-after differences, the reason for the change, and the test target. For example, note “moved an exact domain above the suffix rule to preserve a DIRECT exception” rather than simply “optimized rules.” Periodically remove duplicates, unused exceptions, and obsolete Host mappings, but avoid changing every layer at once. After a remote configuration update, check that local exceptions remain and that their order has not changed.

If a problem is hard to explain, restore the most recent file you verified as working and check whether the basic connection returns. Then reproduce one change at a time in a copy. If the same failure occurs after rollback, the network, service, or subscription status may have changed; do not assume the rule you just edited is the only possible cause. To review the initial connection steps, return to the quick-start guide. For app availability and restoring a previous purchase, see restore a previous purchase. Remove personal credentials before sharing troubleshooting details; include only the minimal rules, request conditions, and observed results.