Advanced v2rayN Configuration
Subscriptions, Routing & Network Modes

Subscription Groups and Server Filters

A subscription URL is the entry point for updating server details; a subscription group is the client-side container that organizes them; and each server entry holds the parameters used to connect. Understand these three objects before organizing the list. Renaming a group usually does not change the remote subscription, and changing the list filter does not switch the active server. When troubleshooting, record the group source, which entries are visible, and which server is active. This helps distinguish changes in the management interface from changes in network behavior.

Create a group, then update its servers

In v2rayN's subscription group settings, create a separate group for each source, enter the full subscription URL, and save it. Then update that group. Choose names that identify the source and purpose, such as “Work” or “Backup”; don't rely on automatically generated server names to tell sources apart. For the first update, use just one group. Confirm that entries load, a server can be selected, and a connection works before adding other sources. If something fails, you'll know which step to investigate.

Subscription URLs may contain access credentials, so treat them like account information. Don't include the full URL in screenshots, public logs, or shared notes. When describing a problem, share only the request method, error type, and a redacted hostname. After copying a URL, check for leading or trailing spaces, line breaks, and punctuation added by a chat app. If the provider offers different formats for different clients, choose one compatible with your client rather than repeatedly trying random links.

If an update fails, start with the subscription update log. A timeout means the request did not finish in time; an authentication error usually points to authorization details in the URL; a successful response that fails to parse may be a login page or an incompatible data format. If you already have a working connection, try the client's update-via-proxy option. That may not be available on first import, so don't assume it will fix the problem. Never post a raw response publicly if it contains sensitive information.

Filter the list without changing connection settings

Server filters help narrow the choices—for example, to entries whose names include a region, or to hide tags for uses you no longer need. First check which group the filter applies to and whether it searches names or other fields, then enter your criteria. Plain text and regular expressions use different syntax. Use regex only when the interface explicitly supports it; otherwise, characters such as parentheses and vertical bars may be treated literally. After filtering, verify the active server manually.

If the filter explicitly supports regular expressions, use the expression below to match either of two name keywords. This is only a name filter: it says nothing about connection quality or where traffic exits. Providers control server names, and changes to capitalization, spacing, or naming can affect matches. Check the actual entries first, then narrow the criteria gradually. An overly restrictive filter can make an entire group look empty.

(Hong Kong|Singapore)

If the list is empty, clear the search term, remove any extra filters, switch back to all groups, and check the update log again—in that order. Don't delete the subscription right away; local display filters may be the only problem. Server filtering is also different from application routing: a filter controls which servers appear in the list, while routing rules decide which outbound handles a connection. Even if only one entry remains visible, existing connections may still use their previous route.

Handle update overwrites and local edits

A subscription update may replace server entries managed by its source. If you edit a server's port, transport settings, or notes directly, expect an update to overwrite those changes. For adjustments you need to keep, copy the entry into a separate, manually managed group and note its source and why you changed it. This lets you continue updating the original subscription while tracking when the manual copy needs to be synced. Don't mistake a manual copy for an entry that will keep updating automatically.

Before deleting a subscription group, check whether the client will also delete its servers and whether the active server belongs to that group. Deletion behavior varies by interface, so read the confirmation prompt. Export or copy any entries you need to keep, and back up the subscription URL securely. Exports that contain URLs are sensitive too. After restoring a backup, check the group's enabled status, update settings, and active server—not just whether the group name appears.

V2Ray Routing Rules in Practice

Routing sends connections that have already reached the core to an outbound. It does not automatically bring applications that bypass the client into the proxy. Before configuring rules, confirm that the target app uses the client's local entry point or is captured by TUN. Otherwise, even perfectly valid rules won't help: the core cannot see the connection, so the expected match won't appear in the logs. Confirm the entry point first, then check the rules, and finally inspect the outbound. This is more reliable than repeatedly rearranging rules.

Set rule order from top to bottom

Common routing fields in Xray and V2Fly are matched in order, and the first match determines the outbound. Put explicit blocks, private-network direct connections, and precise exceptions before broad rules, followed by larger domain lists. Then check the default behavior when no rule matches. There is no universal ordering: if an internal domain must use a dedicated proxy, put its exact rule before any direct-connection list that could catch it.

The following Xray routing snippet illustrates rule order and must be merged into a complete configuration. It assumes outbounds named proxy, direct, and block already exist, and that the referenced rule data is available. Tags are local identifiers; writing a name does not create an outbound. If the client generates different tags, update the references to match the actual configuration.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

This snippet does not include a catch-all rule. In the common core configurations discussed here, unmatched connections usually go to the first outbound in the list; clients may also implement their own default policy by generating extra rules. So “final → proxy” illustrates a policy—it is not a field you can paste into the JSON above. To verify the default behavior, inspect the generated configuration and runtime logs rather than inferring it from the mode name in the interface.

Distinguish domain matches from IP matches

Domain rules need a usable domain name for the connection. If an app connects directly to an IP address, or the entry point supplies only the destination IP, a domain rule may not match. Protocol sniffing can recover a domain for some connections, but it does not work for all encrypted traffic and cannot reliably restore every domain. Check whether the destination appears as a domain or an IP in the logs, then decide whether to use a domain list, an IP range, or investigate DNS and the information passed through the entry point.

domainStrategy controls when routing tries to resolve a domain during rule matching; it does not mean that all app DNS is intercepted. AsIs does not proactively resolve domains for IP rules. IPIfNonMatch can try resolving a domain if no domain rule matches, then check IP rules. IPOnDemand tries to resolve a domain when a rule needs an IP. Changing the strategy affects query volume and match results. Test it alongside your DNS setup rather than assuming more aggressive resolution is more accurate.

Verify rules with one specific destination

Each time you add a rule, pick one destination you can reproduce clearly. Close old connections, reconnect, and check the destination and outbound tag in the access log. Browser keep-alive, connection reuse, and app caches can leave old connections on the previous route. Refreshing a page may not create a new connection; if needed, quit and reopen the app while leaving other settings unchanged. The logs should tie the test time to the destination and outbound—not just show that the client is running.

If a rule does not take effect, check in order whether an earlier rule matched first, the tag exists, the rule data loaded, and the connection includes a domain. If the rule matched but the request still failed, investigate the outbound and DNS instead of adding duplicate rules at the same layer. Updates to rule data can also change what a list covers, so spot-check common services after updates. Brief notes on each rule's purpose are more useful for finding conflicts than a pile of overlapping exceptions.

DNS Setup and Resolution Paths

Start DNS troubleshooting by answering three questions: who sends the query, how it reaches the resolver, and who uses the result. An app may resolve a name itself, the operating system may serve a cached result, and the core may make its own query for routing or a connection. These paths can coexist. Changing the DNS server in the client may not affect a browser's encrypted DNS or clear the system's existing cache. Map the actual paths before changing servers; simply replacing a resolver address may not address the real issue.

Distinguish system resolution from core resolution

System proxy mode mainly changes connection paths for apps that follow proxy settings; it does not automatically intercept every system DNS request. With SOCKS, whether the local machine resolves the destination or sends the domain to the proxy also depends on the app and how it connects. TUN with DNS interception can cover more requests, but you still need to check routing, captured ports, and app-specific DNS settings. Turning on TUN alone does not guarantee every system query follows the same resolution path.

v2rayN core DNS, TUN-related DNS, and desktop system DNS may be configured in separate places. Before making a change, note the current mode and supporting components, then check which component reads the setting you want to edit. On Android, v2rayNG and v2flyNG also depend on the VPN service and per-app selection. Carry over the intended policy between platforms rather than pasting desktop configuration into an arbitrary mobile setting.

The following V2Fly-style snippet shows built-in DNS configuration; check support in your specific Xray core. It demonstrates a standard UDP resolver and query strategy, but does not enable encrypted DNS or configure the outbound path for queries. Choose an address based on network reachability and your requirements. After merging it, check the generated configuration, routing, and logs.

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53
      }
    ],
    "queryStrategy": "UseIP"
  }
}

Choose a resolution strategy for each use case

For direct traffic, the resolved address needs to be reachable through the local network. For proxied traffic, consider whether the resolver's location matches the egress network. Some services return different access addresses based on the resolver's location, so a successful lookup can still lead to an unstable connection. If you route queries to different resolvers by domain, start with precise, understandable scopes before expanding to rule lists. Don't confuse fallback on resolution failure with routing-based query selection: they have different triggers and query paths.

With an encrypted DNS URL that uses a hostname, consider how the resolver's own address is resolved. This is often called bootstrap DNS. If it must go through a proxy that isn't established yet, while the proxy server's address depends on that same resolver, startup can get stuck in a dependency loop. Set an explicit bootstrap resolution path or use the client's separate bootstrap DNS option. Adding more fallback servers indefinitely won't fix a loop; they may have the same dependency.

Test IPv4 and IPv6 separately. Getting both address types in a DNS response does not mean both have a working route, and the address family the system tries first may not be the one you expect. If some sites take a long time to load or fail only on certain networks, check IPv6 routing and whether the proxy server supports the relevant address family. Returning only IPv4 can help as a comparison test, but choose a long-term policy based on network capabilities and note whether it affects other apps.

Cross-check DNS answers against connection results

The command below checks the operating system's default DNS path; by itself, it does not show which resolver the proxy core used. Record the responding server, address family, and any errors, then compare them with DNS events in the client logs. If the core did not make a query, it may have used a cache or received an address from the app. Find out which before changing the configuration.

nslookup example.com

Clear caches in layers: restart the target app, clear the system DNS cache using the operating system's recommended method, then restart the relevant core. Don't change networks, replace the resolver, and restart the device in the same test; you won't know which change affected the result. If the domain resolves but the connection fails, check outbound reachability, certificate time, and destination port. If resolution times out, check the query path and resolver reachability. These failures need different fixes.

Private domains on corporate or local networks usually need an internal resolver or search domain. Sending every query to a public resolver may prevent internal services from resolving. Keep an explicit path for internal domains and test the difference between short names and fully qualified domains. If public sites work but internal services don't, check whether the search domain was lost before changing the proxy server or global routing policy.

TUN Mode and Traffic Capture Scope

TUN uses a virtual network interface to pass selected traffic to a user-space component, making it useful for apps that ignore system proxy settings. It changes the traffic entry point and routing scope; it does not guarantee that every protocol or destination will be reachable. Connections entering TUN still need DNS resolution, rule matching, and outbound handling. Decide whether to enable TUN based on the target app's proxy support, not as a universal fix for connection problems.

Enable TUN in steps you can undo

Before enabling TUN, confirm that a server works in standard system proxy mode. Note the current system proxy status, DNS settings, and local network access. Then close other network-capture tools that could conflict, and grant administrator or network-extension permissions as required by the client. For the first test, enable only the basic TUN options; don't add complex DNS, FakeDNS, or custom outbounds yet. If several features are enabled at once, a loss of connectivity is much harder to diagnose.

v2rayN may use a separate component to manage the TUN interface and routes, so core connection logs may not tell the whole story. Check whether the TUN component started, the interface was created, and the default route changed as expected. On Android, v2rayNG and v2flyNG use the system VPN permission to capture traffic. When prompted, confirm the request comes from the client you are using. If another VPN service is active, check for conflicts first.

Prevent routing loops and keep local access

The proxy server's own connection must not be captured again by the same proxy path, or a routing loop can form. Clients usually prevent this with route exclusions, interface binding, or process handling, but verify after adding manual routes, a custom upstream, or an old configuration. Typical symptoms include the server becoming unreachable as soon as TUN is enabled, repeated similar connections in the logs, or persistent timeouts. Turn TUN off first to restore the baseline; don't add more proxy hops yet.

Local network access depends on both network-level routing and core rules. The route table determines whether traffic enters the virtual interface; core rules decide which outbound handles it afterward. Configuring only one layer may not be enough. When testing a router's admin page, a local printer, or an internal domain, record results for both IP and domain access. If the IP works but the name doesn't, focus on internal DNS. If neither works, check private-subnet routes and direct-connection rules.

Keep app-based routing and destination-based routing distinct. On Android, app selection usually determines which apps enter the VPN; the core then routes their connections. Whether desktop clients support per-process routing depends on the components in use. Don't treat domain rules as process-isolation rules or apply one platform's app-exclusion method to another. For app-level isolation, first confirm what the entry point supports, then choose an implementation you can verify.

Test UDP, sleep, and network switching

A working webpage proves only that the relevant connections work; it says nothing about UDP apps. Voice, real-time communication, and some DNS requests may use UDP. Support also depends on the server, transport, and outbound configuration. First identify the target protocol, then check whether the logs show the connection. If only UDP traffic fails, focus on UDP handling and upstream support. A browser loading a page does not rule out a network-path problem.

Waking from sleep, switching Wi-Fi networks, or reconnecting Ethernet can change the default gateway, DNS, and interface priority. After enabling TUN, test these everyday scenarios: connect first, switch networks, then check whether the component recovers and local network access still works. If it fails after a switch, restart the TUN component and test again. If the issue keeps recurring, record interface and route changes instead of describing it only as “the client disconnected.”

To roll back, turn off TUN first, then exit the client. Check that the system proxy is restored as expected, and test normal internet access and local services. Don't delete unknown virtual interfaces or reset the entire network; that could disrupt other software. If problems persist after exiting, check for leftover DNS, proxy, and route settings in the operating system. Record any unfamiliar setting before changing it so you have a way to restore it.

FakeDNS and Domain Mapping

Instead of returning a real destination IP to the app, FakeDNS assigns a synthetic address from a configured pool and stores a mapping between that address and the domain. When the app connects to the synthetic address, the capture component restores the original domain and passes it to routing and outbound handling. This preserves domain context, especially for transparent capture. FakeDNS is neither a public DNS server nor a source of real service addresses.

Confirm the full processing path before enabling it

Queries and subsequent connections must pass through components that share the mapping for FakeDNS to work. If an app gets a synthetic address and connects directly, outside the capture component, the address is meaningless. If one component assigns the address but another handles the connection without the mapping, the connection may fail. Adding a resolver name to a DNS list is not enough: the address-pool route, traffic entry point, and domain-recovery step must all line up.

v2rayN's TUN component and FakeDNS in Xray or V2Fly are not interchangeable settings in a single shared system. Different cores and helper components may use different fields, address pools, and mapping lifetimes. First confirm which component actually handles the traffic, then choose the corresponding mechanism. If the client offers a complete preset, prefer it and inspect the generated configuration. Don't paste fields from another core into the current configuration to fill in a feature that only appears to be missing.

The following Xray configuration snippet shows the FakeDNS-related address pool and DNS selection. It is not a standalone configuration: the actual entry point must also restore domains, and synthetic addresses must be captured. The example uses a benchmarking address range, not a real service address. If your network already uses the same range, resolve the conflict before using it.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

Understand the address pool and mapping lifetime

ipPool sets the assignable address range; poolSize sets the pool capacity. Pool capacity is not a throughput metric or a measure of how many connections can stay active. Apps may cache addresses for a long time, while restarting the core may erase its mappings. If an app then connects using an old synthetic address, the new process may not know which domain it represents. After enabling, disabling, or restarting related components, have target apps resolve their domains again.

DNS cache and mapping cache lifetimes can differ, causing intermittent failures. FakeDNS may work at first, then fail for a few apps after a restart, and work again after clearing app caches. When troubleshooting, note whether you switched modes, restarted the core, or resumed from sleep before the issue began. Increasing the pool size won't fix lost mappings for old addresses and may make cached results harder to trace.

Some apps need real IP addresses for network checks, region detection, or direct protocol exchanges. They may also use their own encrypted DNS and bypass the expected query path. If this causes compatibility problems, use real DNS for specific domains or apps, and make sure their connections follow a matching route. Keep exceptions precise: test one destination first, then expand to related domain lists. Excluding too much traffic can defeat the domain-mapping behavior you intended to keep.

Test resolution, domain recovery, and outbound separately

First, confirm the query returns a synthetic address in the expected pool. Second, check that a connection to that address shows the recovered domain in the logs. Only then check which rule and outbound match the domain. A synthetic answer proves only that the first step worked. If the logs show only the synthetic address and no domain, investigate the capture entry point and domain-recovery settings before adding rules for real destination IPs.

When routing includes IP rules, distinguish synthetic addresses from real resolved addresses. Treating a synthetic address as an ordinary target for geolocation or private-IP checks can produce results unrelated to the intended policy. Specify which decisions use the recovered domain and which require real DNS. Connections that need IP matching may still need a real query, so FakeDNS does not mean every scenario can skip further DNS processing.

To disable FakeDNS, restore normal DNS settings first, then disable capture for the address pool. Restart target apps and clear any stale caches. If an app still tries to access a synthetic address, its cache may not have updated; changing servers repeatedly usually won't help. After restoring normal resolution, check regular DNS and local network services again. Use FakeDNS in daily configurations only if you can enable it reliably, verify it clearly, and fully disable it when needed.

Manage Multiple Subscriptions and Update Policies

Managing multiple subscriptions is about separating sources, scheduling updates, and making changes recoverable—not automatic load balancing. After importing several sources, the client may still use only one active server; the rest are candidates. Decide which subscriptions support daily work, which are backups, and which are kept only for reference, then organize groups and updates accordingly. The goal is to understand changes when they happen, not to keep as many servers as possible in the list.

Organize by source, filter by purpose

Start by grouping subscriptions by source to keep updates traceable. Use notes, keywords, or local filters to distinguish purposes. A single source may include entries for several uses, so there is usually no need to import the same URL repeatedly for each one. Duplicate imports mean more update requests and can put identical parameters in several places, making it harder to tell which copy is current. If you need separate management, document why you copied the entries and how you'll keep them in sync.

Matching names across sources are not a reliable basis for deduplication. Entries with the same name may have different addresses, ports, protocols, or transport settings; the same connection parameters may also reappear under a different name. To identify duplicates, compare their actual parameters and sources, and make a backup first. Bulk-deleting subscription entries may only cause them to reappear on the next update. Prefer display filters, or adjust subscription preferences on the provider's side when possible.

For each source, record at least its purpose, update method, and whether updating depends on an existing proxy connection. You don't need to keep the full credential-bearing URL in ordinary notes. Account expiry, changed credentials, or plan changes can alter the list, and the client cannot infer account status from server names. If many entries disappear, check the source response and account status before restoring an old configuration. Restoring an old list won't bring back remote services that are no longer available.

Set update frequency based on actual changes

Choose an automatic update interval based on how often the source changes and how you use the client; avoid updating too frequently. Repeated retries during a remote outage may trigger request limits and clutter the logs. After enabling automatic updates, observe a complete cycle. Check what happens if the network is not ready and whether updates affect the active server selection. Scheduled tasks may not run as expected if the client is closed or the system restricts background activity.

Updating through a proxy and updating directly are separate access paths with different dependencies. If the active server comes from the subscription you're trying to update and that server is down, updating through the proxy may fail too. Switch to another verified source before updating the affected group, or try a direct update if that path works. Don't change the update method for every group at once, or you won't know whether the issue is specific to a source or affects the shared network path.

Tracking the server count before and after an update can help with troubleshooting, but the count is not a service-quality metric. More important checks are whether the active entry remains, its parameters changed, local notes were kept, and essential services still work. Verify your current use cases after an update before cleaning up the list. If the client can preserve the selected entry during an update, test that behavior; don't assume matching names identify the same server.

Keep speed tests, switching, and service checks separate

Latency tests, connection tests, and real-world app checks measure different things. A successful test does not guarantee that long-lived connections, UDP, or specific domains will work; a failed test may also reflect the test target or DNS path. With multiple subscriptions, test groups in batches to reduce interference, then confirm with the apps you actually use. Don't treat one ranking as a long-term selection policy or the list order as proof that the client has switched servers automatically.

After manually switching the active server, existing connections may continue using the old path. To verify a backup, start a new test connection and check its destination and outbound in the logs. With custom routing or a fixed outbound, some traffic may not follow the main server selection; that can be the intended policy rather than a failed switch. Keep a short note on which apps follow the main selection and which use a fixed exit to avoid confusion during an outage.

Back up group settings, manual entries, and local rules, and restrict access to the backup. When restoring, import the base configuration first and verify each source before restoring complex rules. Don't overwrite a working setup with an old, complete snapshot. To retire a source, disable its updates and remove active references first; delete it only after confirming nothing depends on it. This makes rollback possible within clear boundaries without reorganizing every subscription.

Custom Outbounds and Configuration Rollback

An outbound defines how the core sends a connection to the next network hop; routing decides which outbound to use. Clients usually create the necessary outbounds when you switch servers. Custom outbounds are useful for a fixed exit, explicit direct or block policies, or connecting to a local proxy service. Before editing anything manually, confirm that the policy cannot be expressed through the standard configuration. If the interface can manage a setting reliably, there's usually no need to duplicate it in a custom config.

First, identify who controls the configuration

v2rayN may regenerate its runtime configuration at startup or when you switch servers, so direct edits to a temporary generated file may not persist. Use the client's supported custom configuration option and distinguish between importing a complete configuration and merging a snippet. A complete configuration must include all required inbounds and outbounds; a snippet depends on merge behavior. Choosing the wrong option may overwrite existing structure. Before editing, save the working settings and note which file you'll need to restore them.

Xray and V2Fly both use concepts such as inbounds, routing, and outbounds, but supported protocols and field details differ. TUN helper components may use yet another configuration structure. Two JSON files are not necessarily interchangeable. Check which core actually runs before deciding where a field belongs. To understand how the client and core fit together, read How Project V, V2Fly, and Xray Fit Together rather than inferring every internal capability from the client name.

The following snippet shows two common Xray outbounds. freedom connects directly to the destination; blackhole drops the connection. Their tags can be referenced by routing rules. This does not include a proxy-server outbound and must not replace a complete outbound list. If you put direct at the top without a suitable fallback policy, unmatched connections may go direct. Check additions and ordering together.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

Connect rules to outbounds with tags

Keep tags short, unique, and descriptive. When changing a tag, update every reference in routing, chained forwarding, and other settings. Renaming an outbound without updating its references can prevent startup or cause runtime routing failures. After adding an outbound, test it with one precise domain rule; don't assign a broad domain list to it right away. This lets you verify tag references, the connection path, and log output before expanding its use.

When connecting to a local SOCKS service, confirm it is listening on the specified address and port before adding the outbound. A loopback address is appropriate for use on the same machine; don't expose the service on every network interface just for convenience. Loopback addresses can also mean different things in containers and separate network namespaces. If the connection is refused, check the listening process and address scope before changing routing rules. For timeouts, also check the firewall and network reachability.

Chained proxies add dependencies: if an earlier hop is unreachable, later hops cannot connect; if one hop doesn't support the target protocol, only some services may fail. Simply listing several subscription entries in an array does not create a chain—the array order alone does not define one. Configure forwarding according to the core's supported mechanism and check for self-references. Fill in credentials securely on your own system; never put real credentials in public configuration examples.

Validate syntax, references, and connectivity

First, check JSON syntax: commas, quotes, brackets, and field types. Next, validate semantic references: tags exist, protocol fields are supported, and rule data can be loaded. Only then test connectivity. Passing a syntax check proves only that the file can be parsed; it does not prove the server is reachable or routing matches your intent. If the client offers a configuration test, run it before starting. On failure, save the first useful error instead of letting repeated log messages bury it.

Adjust log verbosity temporarily as needed for troubleshooting. Detailed logs can help trace connection paths, but may also record destinations and network information, so limit retention and restore the normal level when done. Remove subscription URLs, user identifiers, and credentials before sharing logs. If the core won't start, check the configuration test output first. If it starts but only some connections fail, reproduce the issue with a precise destination instead of reinstalling the client or rewriting the entire configuration.

Prepare a rollback plan before editing: save a working baseline, record each new field and its expected result, and decide how to restore the client's automatic configuration mode. After each change, separately test default access, an exact rule, local network access, and system networking after exit. If only a new rule fails, remove that rule; if the entire core won't start, restore the full baseline. A small rollback preserves changes already known to work and is easier to troubleshoot than clearing everything at once.

After a system upgrade, core change, or client migration, repeat the same acceptance checks. Old fields may no longer apply, and defaults may have changed; a file loading successfully does not guarantee identical behavior. Keep concise notes explaining what each custom setting solves, which component it depends on, and how to verify it. When a setting no longer serves a purpose, remove it and test again to keep the configuration understandable and recoverable.