mkshare3.github.io: a daily-updated list of free proxy subscription links

What the repository actually contains

Strip away the formatting and mkshare3.github.io is one file: a README that GitHub Pages serves as a web page. The repository tree lists README.md and nothing else. Its content is a set of subscription links for proxy clients, refreshed with a timestamp (the README shows a last update of 2026-08-21 20:55:49), wrapped in promotional text and a referral to a paid proxy service the author calls an airport. There is no code, no build, no configuration schema. Calling this an open source project stretches the term. It is a distribution point for links, published through a Git repository. Who is it for? People on heavily filtered networks who want a free proxy subscription they can paste into a client without paying. That audience is real, and so are the trade-offs.

How the subscription links reach Clash, v2rayN and Shadowrocket

The mechanism is the subscription URL convention that proxy clients already understand. A client such as Clash, v2rayN or Shadowrocket fetches a URL, receives a list of server entries in the format it expects, and fills its node list from that response. The README publishes a single subscription URL, hosted on a third-party domain (mcsslk.xyz), and offers it for all three clients, which means one endpoint serves a format each can read. You paste that URL into the client's subscription screen and it pulls the current nodes. The README says the nodes are speed-tested and updated in real time, which you cannot verify from the repository. Nothing here is built by the project. The servers live behind that external domain, and the repository is only the page that points at them.

Using a published subscription without paying

There is no installation in the software sense. The README's own instructions amount to three moves: install a proxy client, open its subscription or profile screen, and add the subscription URL the README publishes, which is the same for all three clients:

https://CFpxbl.mcsslk.xyz/20701a1073ae305a61b1094cb6bb477a

After the client fetches that subscription, its node list fills with the current servers, and you pick one to route traffic through it. The README documents no configuration file to edit and no API; the subscription URL is the only value you supply. That is the honest state of the project: it is a link you subscribe to, not a program you configure. Because the same URL is offered for Clash, v2rayN and Shadowrocket, a single client is enough to test whether the nodes respond before you commit to anything.

The trust problem with anonymous rotating nodes

This is where a review has to be blunt. When you route your traffic through a proxy you do not control, the operator of that proxy can see the destinations you connect to, and for unencrypted connections, the content. Free public nodes shared through an anonymous README give you no operator identity, no privacy policy and no accountability. The nodes rotate, so a server that behaves today may be gone or replaced tomorrow. The README pairs the free links with a referral to a paid service, which is the actual business model: the free list is a funnel. None of this makes the links unusable, but it sets the risk. For anything sensitive, an untrusted shared proxy is the wrong tool, and the project offers nothing to reduce that risk, because there is nothing in the repository except the links themselves.

Free shared links versus a paid airport or a self-hosted server

The README itself lays out the alternative, and it is worth taking seriously. It argues that self-hosting a proxy on a rented VPS, once a common approach, has grown unreliable as filtering has improved and provider IP ranges get blocked, sometimes within weeks, with paid IP changes offering no guarantee. Its recommendation is a paid provider with a large IP pool and custom obfuscation, which is also the service it refers you to. So the real comparison is three-way: free shared links (no cost, no trust, unstable), a self-hosted VPS (full control, real maintenance burden, increasingly blocked), and a paid provider (a cost, but more IP capacity and someone to rotate blocked addresses). This repository sits at the free-and-unstable end. Its content is a reasonable way to test whether such nodes work for you before paying, and a poor foundation to depend on.

No license, no source, and a single tracked file

The repository carries no license file, which for a page of links matters less than for code, but still leaves reuse rights unstated. There is no source to audit, no releases, and the only tracked file is README.md. Maintenance shows as a timestamp in the README (2026-08-21) and a last push on the same date, rather than a version history you can inspect. Treat this the way you would treat any anonymous link aggregator: the update cadence is whatever the author chooses, the links can change without notice, and there is no channel to report a broken or hostile node beyond the external service being promoted.

Editorial conclusion

Use mkshare3.github.io only as a throwaway way to test free proxy nodes, never for traffic you would mind an unknown operator seeing. Do not treat it as a project to depend on or contribute to, because it is a single README that points at third-party servers and funnels toward a paid service. If you need reliability, the README's own argument points you to a paid provider or a self-hosted VPS; if you need privacy, confirm your client uses an encrypted protocol and assume the node operator can log everything else.

Frequently asked questions

Official sources

1. Issues
2. mkshare3/mkshare3.github.io on GitHub
3. Project website
4. README