Pawdroid/Free-servers: a free Clash and V2Ray subscription feed, reviewed

What Free-servers actually publishes

The repository is a distribution channel, not a proxy service. It hosts a README, a static/ directory of translated README files, a file named sub, and two QR images, sub.png and sub2.png. The sub file is the product: a subscription document that proxy clients can fetch on a schedule. The README states that the list is refreshed every six hours and that the page shows at most 20 nodes, with the rest available through the ShadowShare app.

The audience is people who already run a client. The topics attached to the repository name clash, shadowrocket, shadowsocks, ss, trojan, v2ray, vless, vmess and xtls, which is the vocabulary of client configuration rather than of server hosting. If you do not already have a Clash-family or V2Ray-family client installed, this project gives you nothing to run.

The nodes are shared. The README uses the phrase 共享节点 for them, and the same Trojan password, humanity, appears across a large block of the sample entries. That single shared credential is the clearest signal of what kind of service this is: many users on one endpoint, with no per-user accounting and no way for the operator to tell you apart from anyone else.

The node formats in the feed, and what the sample shows

Three URI schemes appear in the README's sample block: trojan://, vless:// and vmess://. The Trojan entries dominate, and most of them point at CloudFlare anycast addresses such as 104.16.x.x and 104.18.x.x on port 443, with security=tls, type=ws, path=/assignment and sni=www.ignitelimit.com. Different entries carry different country labels in their fragment, including the United States, France, Canada and Poland, but the underlying host is frequently the same CloudFlare edge. A country label in a URI fragment is a comment, not a geolocation guarantee.

The vless entries use a different shape. One carries flow=xtls-rprx-vision, security=reality, a pbk public key and an sid, which is the Reality transport. Another uses security=none over WebSocket on port 8880 with a host under workers.dev. The vmess entry is base64-encoded JSON, which is the standard vmess URI form.

This mix matters when you choose a client. A client that only understands vmess will silently drop most of the list. The README points readers at ShadowShare and at shadowrocket_for_android, and it names Clash in the repository description, so the intended clients are the ones that parse all three schemes.

Adding the subscription to a client

There is no package to install and no binary to build. Setup means copying a URL into a client that supports subscription import. The README gives two permanent subscription addresses, one on raw.githubusercontent.com and one through mirror.v2gh.com, plus QR codes for both.

The first address is the canonical one. In a client that accepts a subscription URL, paste it into the subscription or profile field and trigger an update:

https://raw.githubusercontent.com/Pawdroid/Free-servers/main/sub

If raw.githubusercontent.com is unreachable from your network, the README provides a mirror variant that prefixes the same path with mirror.v2gh.com:

https://mirror.v2gh.com/https://raw.githubusercontent.com/Pawdroid/Free-servers/main/sub

After the update, the client should list the nodes from the feed and let you select one. What you should see is a node list whose entries match the schemes above. What you should not expect is a working connection on the first pick: the README itself warns that different carriers and regions behave differently and that some nodes may time out. The practical workflow is to import, run the client's latency test, and discard the dead entries before browsing.

For the app route, the README directs readers to ShadowShare at shadowsharing.com and, for Android, to the Pawdroid/shadowrocket_for_android repository, which it says has all free nodes built in. It also recommends that iOS users in China download ShadowShare from the App Store early, noting the app may be removed later. That is a distribution warning, not a technical one, and it is worth taking at face value.

Shared credentials and the trust problem

Every Trojan node in the sample uses the same password. When a credential is published in a public repository and reused across endpoints, everyone who fetches the feed is on the same footing as you. The operator of the endpoint can see the metadata of your traffic, and so can anyone else who has the same credential if the endpoint is misconfigured. TLS to the SNI host protects the content of an HTTPS request, but the endpoint still learns which hosts you contact.

This is a structural property of free shared nodes, not a bug the maintainer forgot to fix. It is also why the README's own framing matters: nodes are described as measured one by one, with a note that regional networks differ and some may time out. Measurement of reachability is not a security audit.

The repository publishes no licence file, and the top-level listing contains only README.md, static/, sub, sub.png and sub2.png. With no licence, there is no stated grant to redistribute the node list, embed it in an app, or resell access. If you are considering building anything on top of the sub file, that absence is the first thing to resolve, and it is a question for a lawyer rather than for this article.

Where the six-hour refresh promise breaks down

The README states a six-hour update cadence, and the last push to the repository was on 2026-09-20. Cadence is a claim about the maintainer's routine, not a contract. Nothing in the repository guarantees that a given endpoint stays reachable between refreshes, and nothing guarantees that the sub file changes at all in a given window.

The failure mode is familiar to anyone who has used a public subscription: you import a list of twenty nodes, half of them are CloudFlare edges that resolve but do not complete a handshake, and the remainder work for a few hours before the operator rotates the password or the host goes dark. The README's own line about nodes timing out is the honest version of this.

The second failure mode is subtler. Because many entries share one SNI host and one path, a client that sorts by latency may present you with what looks like twenty locations when it is closer to three or four distinct backends. If you need geographic diversity for a specific reason, this feed is the wrong instrument. It is also the wrong tool if you need stable throughput for large transfers, a fixed exit IP for allowlisting, or any form of support when a node stops working.

How it compares with self-hosted and commercial options

The nearest alternative in kind is a self-hosted proxy on a small VPS using the same protocols, Xray or sing-box on the server side and a Clash or V2Ray client on yours. The difference is ownership of the credential. On a VPS you hold the key, you know the exit IP, and you can restart the service when it degrades. You also pay for it and you maintain it, including certificate renewal and transport configuration. Free-servers inverts that: zero setup and zero cost in exchange for a shared, rotating, unaudited endpoint.

Commercial subscription providers sit between the two. They also hand you a subscription URL that a client imports the same way, but they sell a service with an operator accountable for uptime. Free-servers publishes no such accountability, which is exactly why it is free.

A different kind of alternative is simply not using a proxy feed at all for the task at hand. If the goal is reaching a specific site from a specific region, a commercial provider with a documented location list answers that question directly. Free-servers offers country labels in URI fragments, and as noted above those labels are not a reliable geolocation signal.

Who should use it, and what to check before trusting it

Use it if you want a zero-cost way to test whether a Clash or Shadowrocket client works on your device, or if you need a disposable path for casual browsing and accept that it may stop working without notice. The import is a single URL, and the cost of a dead node is one more latency test.

Do not use it for anything tied to an identity or a payment. Do not use it as the only route to a service you depend on. Do not build automation that assumes the sub file has a stable schema or a stable set of hosts, because the repository documents neither.

Before relying on it, verify the feed yourself. Fetch the sub URL and confirm it returns a node list rather than an error page. Import it into your client and confirm the client parses the trojan, vless and vmess entries rather than dropping some. Then check whether the nodes you actually receive are distinct backends or the same CloudFlare edge repeated under different country fragments. If you need more than the twenty nodes shown, the README says the rest are in the ShadowShare app, so the app is part of the intended path and its availability on your platform is a precondition.

Maintenance cost is effectively zero on your side and unknown on the maintainer's side. The repository has no releases and no licence, so there is no version to pin and no upgrade path to plan. What you get is whatever the sub file contains at the moment you fetch it.

Editorial conclusion

Adopt Free-servers only as a disposable, low-stakes proxy feed: point Clash or Shadowrocket at the raw subscription URL, keep a paid fallback, and treat every node in it as public and untrusted. Do not route banking, work accounts or anything you would not post in the Telegram group through it, and do not build a product, a scraper or a monitoring pipeline on top of the URL, because the repository publishes no uptime guarantee, no node provenance and no licence. Before relying on it, verify three things yourself: that the sub URL still resolves to a fresh list, that the client imports it without a format error, and that the nodes you actually get are not the same CloudFlare-fronted endpoints repeated under different country labels.

Frequently asked questions

Official sources

1. Issues
2. Pawdroid/Free-servers on GitHub
3. Project website
4. README