Encrypted Subscriptions

Encrypted Subscriptions (age)

🌐 English · Русский · 中文

SlothClash can import subscriptions encrypted with age — the config travels from the panel to your machine as an encrypted blob, so CDNs, caches and anyone inspecting the traffic in between see nothing. This is a Mihomo-family capability few clients expose.

📖 For users

You don't need to understand the crypto. If your provider uses encryption:

1. Copy the full subscription link from your dashboard. It looks like:

   https://panel.example.com/sub/TOKEN#AGE-SECRET-KEY-1XXXX…
   

2. Import it in SlothClash as usual. The app detects the key after #, stores it with the profile, and keeps the URL clean. Updates keep working automatically.

If the import fails because the body is encrypted, you probably copied a link without the key part. Copy the full link again, or paste the key into the profile's Age secret key field by hand.

The part after # (the URL fragment) never leaves your device — browsers and HTTP clients strip it before sending a request. That's what makes one-link key delivery safe.

🏢 For operators

Two things live on your side: encrypt the config, deliver the key.

1. Generate a key pair

In SlothClash you can mint an age identity from the app, or on a server:

age-keygen
# Public key: age1…            ← goes to your panel
# AGE-SECRET-KEY-1…            ← goes to the user

2. Encrypt the subscription body

Your panel (or a middleware in front of it) encrypts the YAML it serves with the user's public key:

age -r age1… -a -o subscription.yaml.age subscription.yaml

Serve the armored output (-----BEGIN AGE ENCRYPTED FILE-----…) as the subscription body. Response headers (e.g. subscription-userinfo) stay plain — SlothClash reads them as usual.

3. Deliver the secret key in the link

Append the secret key as a URL fragment to the link you hand the user:

https://panel.example.com/sub/TOKEN#AGE-SECRET-KEY-1XXXX…

The fragment is never sent over the network, never hits your logs or a CDN. The user imports one link and everything works.

Recommendations

• Per-user key pairs — generate a pair per account. Revoking a user = dropping their key; nobody else is affected.
• The decrypted config is stored locally in the app's private storage (same protection as the node credentials it contains).

Related

• Getting Started
• Deep Links