On this page
Sending the entire file may seem like the fastest way to get help with a configuration error, but it can expose subscriptions and node passwords too. Keep the original recovery backup separate from the support copy: preserve and encrypt the former, and include only the structure and placeholder values needed to reproduce the error in the latter. Check screenshots, scannable codes, and logs as well.
What must be hidden in a troubleshooting attachment?
Check the configuration, logs, and screenshots against the table below, hiding the subscription token, node passwords, controller secret, and internal-network information. Save a separate support copy and verify locally that it still reproduces the original problem. Do not edit the original backup directly; the next section explains how to store it.
Check each item before sharing
| Location or field | What it may expose | How to handle it |
|---|---|---|
| Subscription URL query parameters | A token that can retrieve the entire configuration | Remove the complete URL; retain only the domain and status code |
| proxies entries | server、UUID、password、PSK、private-key | Use example.com and REDACTED placeholders |
| external-controller / secret | Local controller address and API key | Preserve the field structure and replace the real values |
| Logs and screenshots | Authorization, Cookie, username, and QR code | Crop unrelated interface areas and read everything again |
| LAN and corporate domains | Internal addresses, hostnames, and topology | Keep only the smallest scope required to show the issue |
Encrypt the original backup and create a separate minimal troubleshooting copy
Keep the real subscription, nodes and local overrides in the original backup, and store it only in encrypted storage you control. Create a new file for the troubleshooting copy and add only the fields needed to reproduce the problem. Do not create it by deleting content from the original: a long URL, Provider header or script parameter is easy to miss.
A backup filename can include the client, core, and date, such as verge-macos-2026-07-16-private.zip. Compression alone does not encrypt the file. If you store it in the cloud, use the platform's end-to-end encryption or an encrypted archive, and restrict sharing permissions.
Use placeholders to create a minimal configuration whose structure remains understandable
mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: REDACTED
proxies:
- name: test-node
type: socks5
server: example.com
port: 1080
username: REDACTED
password: REDACTED
proxy-groups:
- name: Test
type: select
proxies: [test-node, DIRECT]
rules:
- DOMAIN,example.org,Test
- MATCH,DIRECTIf the problem involves DNS, retain only DNS, one test policy group, and the relevant rules. If it is a YAML parsing problem, retain the hierarchy surrounding the failing line. After substituting placeholders, verify locally that the same error still occurs; otherwise, the shared file no longer demonstrates the original issue.
Perform one final manual check with text search before sending
First enter the directory containing the copy you intend to share; the rg command searches only those files. Run the following Git commands only in an actual Git repository. Enter the relevant repository’s root directory and replace path/to/config.yaml with the configuration file’s actual path relative to the repository root.
git diff --staged shows staged changes, while git log --all checks the relevant history across refs. An error, a wrong path or no matching commits does not prove that credentials were never committed. For a copy outside a Git repository, check the text only; do not treat that as completed history cleanup.
rg -n -i 'token|secret|password|passwd|uuid|private-key|authorization|cookie' .
git diff --staged
git log --all -- path/to/config.yamlSearch can flag common fields, but it cannot identify custom header values, QR codes, or renamed credentials. After reviewing search results, still read every line you plan to share, and inspect terminal prompts, browser tabs, and screenshot notifications.
If the real configuration has already been sent, rotate credentials instead of continuing to redact it
If the original file has been sent to a group chat, support ticket, or public repository, posting a redacted copy can only reduce further misuse; it does not invalidate the old credentials. Replace the exposed credentials so the old values no longer work.
| Exposed content | Immediate action |
|---|---|
| Complete subscription URL | Reset the token/subscription address in the service panel, then update every device |
| external-controller secret | Generate a new secret and confirm that the controller port is not exposed to untrusted networks |
| Node authentication credentials | Have the server administrator replace the password, UUID, PSK, or private key |
| Git history | Revoke or rotate all exposed credentials first, then clean up the history as needed. Deleting only the latest file is not enough. |
| Public log or screenshot | Retract it to limit its spread, and replace every real credential exposed in it |
After rotating, access the old subscription address from a signed-out window or call the controller interface with the old secret to confirm that it truly no longer works. Renaming the client entry or deleting the public post does not replace this verification.
Conditions for sharing configuration, logs and screenshots
Conditions for sending
- The minimal copy still reproduces the same error locally
- All URL query parameters, node authentication values, and secret values have been replaced
- The log contains no Authorization, Cookie, local username, or absolute path
- The screenshot contains no QR code, account details, notifications, or unrelated tabs
- The original complete backup has never entered a public repository or shared link