Official/internal catalog servers
These are proprietary routes kept in the app catalog itself. They can include route metadata, premium flags, transport defaults, and internal-server behavior designed specifically for this project.
Some servers are official. Some are only externally indexed.
The app can show both internal catalog routes and public externally indexed servers. They are not the same in terms of ownership, stability, trust, or operational expectations. Treat public servers as volatile routes, not as infrastructure operated by the app team.
Official/internal versus public/external
Public externally indexed servers
These are gathered from public internet sources and normalized into the catalog format. They are exposed for convenience, not as project-operated infrastructure.
Where the current public server data comes from
| Source | Main type exposed | How it is used |
|---|---|---|
| OutlineKeys public pages | Public Shadowsocks / Outline-style servers | The worker crawls publicly indexed Outline/SS style pages and converts them into app catalog entries. |
| Shadowmere public API | Public Shadowsocks servers | The worker reads public JSON data and normalizes it into Shadowsocks catalog entries. |
| Public GitHub link feed | Public VLESS, VMess, Trojan, and Shadowsocks links | The worker parses public link feeds and keeps only supported entries that can be converted into app server objects. |
Important.
Public sources can disappear, change format, publish invalid data, or go offline without any release from
the app itself.
Why public Shadowsocks appears so often
Easy public indexing
Public Shadowsocks links are easier to surface from public indexes and APIs than many proprietary route families, so they are a natural fit for crawler-based public server ingestion.
Good for quick fallback
They can be useful as “I need a route now” fallbacks, especially when the user wants to test the app or temporarily reach a simple direct route.
How users should treat public servers
Do not assume long-term stability
A public server that works today can vanish tomorrow. Use them as opportunistic routes, not as the foundation of a production tunnel workflow.
Do not assume trust
Because these routes come from public sources, treat them as untrusted infrastructure. Be careful with sensitive traffic and avoid assuming operator identity.
Expect mixed quality
Latency, region labeling, CDN behavior, and throughput can vary a lot. Public feeds are convenient, but they are not curated to the same level as official internal routes.
Prefer official/internal or personal entries for repeat use
If you want stable daily use, keep a known-good official route or save your own personal server/profile instead of depending only on externally indexed public entries.
What the app does with those public entries
Server browser support.
Public servers appear as part of the broader catalog browsing flow so users can test, ping, and compare
them without leaving the same app workflow.
Protocol-aware normalization.
The crawler only keeps entries that can be normalized into supported server definitions. Unsupported or
malformed items are dropped instead of being passed through blindly.
No promise of parity with official configs.
A public server may not support the same custom config or CDN-sensitive profile you use on an official
internal route.
Need the route-matching part too?
Open the CDN guide to understand how config compatibility is grouped, or open Protocols to understand which public link families the app can parse directly.