On this page
First identify whether the subscription link, configuration body, or controller key was exposed
A subscription link is not an ordinary download address. The token in its URL is often enough to retrieve the entire node configuration repeatedly. Posting it in a public group chat, screenshot, support ticket, or online conversion site should be treated as credential exposure rather than ignored until traffic looks unusual.
Scope matters too. If only the subscription URL was exposed, resetting the link usually stops future downloads. If the complete YAML was public, it may already contain server addresses, UUID values, passwords, or private keys; changing only the subscription token does not invalidate that old configuration. The Dashboard secret and subscription service account password are separate credentials that must be rotated independently.
Exposed content and response scope
| Exposed content | What someone else may obtain | Required response |
|---|---|---|
| Complete subscription URL | Continue downloading or updating your configuration | Reset/revoke the subscription link and update every client |
| Raw YAML or QR code | Existing node credentials in the file | Ask the provider whether node credentials must be rotated |
| Service-site account | Plan, device, payment, or subscription-management permissions | Change the password, sign out other sessions, and enable available two-factor authentication |
| external-controller secret | Control Mihomo when its port is reachable | Rotate the secret and tighten listener and firewall restrictions |
Invalidate old credentials before deleting posts and screenshots
The first step after discovering exposure is to open the subscription service's own panel and look for “Reset Subscription,” “Update Subscription Address,” “Revoke Link,” or an equivalent action. If no option exists, contact the provider immediately and ask them to invalidate the old URL. Deleting the public message is insufficient: a bot, browser cache, or another person may already have saved the link.
After resetting, store the new link in a password manager before sending it to any device. Confirm with one client that the new address updates, then check the old address through the service panel or a controlled local environment. The old address should return 401, 403, 404, an expiration notice, or no longer return the original configuration. If it still downloads the full content, revocation is incomplete. Do not leave a second complete token in terminal commands, screenshots, or the browser address bar.
Emergency sequence
Preserve minimal evidence
Record the exposure time, location, and type without forwarding the complete link.
Revoke the old URL
Reset it in the service panel; contact the provider if there is no self-service option.
Verify that the old URL is invalid
Check only its status and whether it still returns a configuration; do not put response content in public logs.
Update one device
After confirming the new link works, replace it on the remaining clients.
Delete public copies
Retract posts, ticket attachments, screenshots, and code snippets to reduce further distribution.
Trace the copy path; the original link often appears in more than one place
Reconstruct your troubleshooting path. Did you include a curl command in a terminal screenshot, or put the URL in a Git repository, chat history, cloud note, browser bookmark, CI variable, or online YAML checker? Query parameters containing a token may also enter Web server access logs and Shell history.
Cleaning these copies does not make the old token safe again. It prevents new people from continuing to misuse it and stops search engines or collaboration tools from displaying sensitive information indefinitely. For content committed to Git, changing only the latest file is insufficient; follow the repository's process to clean history and rotate credentials. History rewriting never replaces revocation.
Locations often overlooked
- Group chats, forums, and customer-support ticket attachments
- Address bars, QR codes, and terminal commands in screenshots
- Git commit, Issue, CI logs, and environment variables
- Shell history, clipboard sync, and cloud notes
- Online subscription conversion, YAML validation, or benchmark pages
- Backups from old phones, old computers, and uninstalled clients
If the full configuration was exposed, determine whether node credentials can be used independently
A subscription token controls whether someone can obtain the configuration. UUID values, passwords, private keys, and other authentication fields inside nodes control whether someone can connect to the server. If the public content includes the latter, an attacker may keep using old nodes without the new subscription until the provider rotates or invalidates those node credentials.
Users usually cannot rotate server-side node credentials themselves. Tell the provider the exposure time and configuration type, and ask whether old nodes will be replaced and whether unusual devices or traffic can be reviewed. Do not resend the raw YAML as proof; provide only redacted node names, protocol types, and the necessary times.
Replace the configuration on every client and confirm that the old one no longer updates automatically
After confirming that the old link is invalid, update devices. Delete the old subscription entry on the primary device, add the new address, and update it manually. Once the new update time, policy groups, and node list appear, set it as the current configuration. Replace it separately on other computers, phones, routers, and WebDAV-synced copies. Updating only one device lets another scheduled task continue requesting the old token.
OpenClash on a router, a server cron job, or a container environment is easy to miss. Review scheduled subscription-update logs and confirm that the old URL no longer produces repeated 401/403 entries. If devices request the invalid link every hour, another configuration still needs cleanup.
Evidence that replacement is complete
- Every active device updates with the new link
- The old link no longer returns the original configuration
- The service panel shows no unrecognized device or unusual traffic
- Scheduled-task logs no longer request the old token
- Sync and backups do not restore the old address
Never give the raw subscription link to an unfamiliar conversion site
A conversion site must first read your subscription URL and usually download the complete configuration before producing another format. The operator can therefore see the token, node addresses, and node credentials. HTTPS protects data in transit only; it does not guarantee that the site will not log, cache, or reuse that content.
If the client can import directly, conversion is unnecessary. When formats genuinely differ, prefer the conversion entry provided by the subscription provider or run a reviewable local tool on a device you control. Even then, confirm whether the output link is publicly guessable, whether the service retains history, and whether the old token can be reset at any time.
How to choose when conversion is required
| Method | Risk assessment | Recommendation |
|---|---|---|
| Direct client import | The raw URL is given only to a client you use | Preferred |
| Provider's official converter | The provider already holds the subscription, but you must still inspect output-link and retention rules | Use after reviewing the terms |
| Self-hosted conversion tool | Data stays in an environment you control, but you are responsible for updates and access control | Suitable for users who can maintain the service |
| A free conversion page found through search | The operator, logging, and retention period are unknown | Do not submit the raw link |
Leave only the information genuinely needed for troubleshooting in public logs and screenshots
When a subscription update fails, you usually need to provide only the client and core versions, HTTP status code, Content-Type, original error text, and time. For the URL, keep the domain and path type but hide the token, query parameters, username, password, and node address. For a YAML error, show only the surrounding structure and replace real values with example.com and REDACTED.
Logs may also contain Authorization, UUID, Dashboard secret, and internal addresses. Read the redacted version again; do not cover only the browser address bar. A QR code or terminal history can expose the same link again.
客户端：Clash Verge Rev x.y.z
内核：Mihomo x.y.z
订阅域名：example.com
token：REDACTED
HTTP 状态：403
错误：subscription update failed at 10:32Treat subscriptions like passwords so you do not need to rely on memory next time
- Storage
- Save the raw link in a password manager, encrypt configuration backups, and do not put a token in the filename.
- Sync
- Use separate credentials and least privilege for WebDAV, cloud storage, and CI, and verify the sharing scope.
- Screenshots
- Crop the address bar, QR code, and configuration details before uploading to a ticket.
- Logs
- Enable URL redaction; before publishing, search for fields such as token=, Authorization, password, and uuid.
- Departure or device replacement
- Remove authorization for old devices and clean local configurations. Reset the subscription if you cannot account for every copy.
The incident is truly over only when the old subscription no longer works, necessary node credentials have been rotated, every legitimate device uses the new link, and old values no longer appear in public locations or automated tasks. “The post was deleted” alone is not completion.