# zieng2/wl: an hourly VLESS subscription whose mirror table does not match its own files

> A four file repository publishing a server configuration subscription for use during mobile network restrictions, refreshed hourly and mirrored on three hosts, with two experimental mirrors pointing at a filename the repository does not contain. There is no code here, no client, and no license file.

**zieng2/wl** — Подписка для обхода белых списков

- Repository: https://github.com/zieng2/wl
- Website: https://t.me/zieng2
- Stars: 2,858 · Forks: 72
- Language: Unknown
- License: not declared
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/zieng2-wl

## Four files sit in the repository, and only one of them has a documented mirror address

The listing holds exactly four entries: README.md, vless.txt, vless_lite.txt and vless_universal.txt. That is the whole repository. No client, no generator, no scripts, no schema, nothing that would tell you how the lists are produced or filtered before publication. The README is the documentation, and it is written in Russian; there is no translated version in the listing. The mirror table gives one address per host, and all three of those serve the same file, vless_universal.txt: one on GitHub, one on Codeberg, one on GitLab. The other two lists, vless.txt and vless_lite.txt, are not named by any address in the visible text. Whatever distinguishes a lite list from a universal one, the difference is not explained anywhere a reader can reach, and the naming implies a smaller variant that nobody is told how to obtain.

## The experimental mirrors name list_universal.txt and branch master, and neither matches the tree

Below the main table the README offers two mirrors under the heading of experimental ones, described as available when connectivity is restricted: one on Mos.Hub and one on GitVerse. Both point at a file called list_universal.txt. No such file exists in the repository, whose universal list is vless_universal.txt. So the fallback path for exactly the situation the fallbacks exist for, a restricted network, is the one path whose filename does not line up with the tree. The GitVerse address adds a second discrepancy: it asks for the master branch, while the repository's default branch is main and the other four addresses all use it. None of this can be resolved from the listing alone. What can be said is that the two addresses meant to be the safety net are the two that disagree with the repository on both filename and branch.

## The deliverable is the subscription link, not the file behind it

One instruction is repeated in bold because getting it wrong produces a silent failure: the client has to be given the address of the subscription, not the contents of the file. Pasting the server list as text is therefore not the supported path, since the whole point is that the client refetches it. The README says the server list is updated once an hour, that all mirrors are updated at the same moment, and that readers should check the availability of several variants rather than trusting one. It also asks readers to apply the subscription for its intended purpose. Underneath those lines sits the honest caveat, in a quoted block about current conditions: the whitelist situation changes dynamically, the lists differ by mobile operator, servers with configured profiles get blocked, and a profile's lifetime can run from several minutes to a full day. An hourly refresh schedule is what that lifetime demands, not a sign of stability.

## Every documented path asks you to turn on allow insecure before the list becomes useful

The step after adding the subscription is to open the client settings and enable the option translated as allow insecure. The README is careful about where that option lives: some clients have it as a global switch, some only per subscription, and if it is missing entirely no extra action is needed. It states the reason plainly, that turning it on increases the number of available servers. In practice that setting relaxes the certificate checking a client applies to the servers it dials, which is consistent with a feed whose profiles are short lived and frequently blocked, and it is also the reason a reader should read their own client's documentation before flipping it. What the text does not do is describe the setting, list which of the recommended clients implement it per subscription, or say what a client does when the option is absent.

## The auto-select balancer prefers Russian servers on latency, which is the opposite of the point

The recommended steady state is not a fixed server but a balancer that switches to the next profile when the current one stops working, described as nearly seamless switching for long sessions. The README then names the failure mode of that balancer, and it is a good one: every configuration name starts with a country flag emoji, and without a name filter the balancer keeps choosing Russia, because Russian servers have the lowest latency from inside Russia. A latency driven balancer therefore optimizes for exactly the servers that are not on the whitelist and therefore not the ones you need during restrictions. The fix is a name filter that removes those entries, and the README notes that the same filters must apply to the balancer, not only to the manual list, or it will keep drifting back. It names Karing and Exclave as the clients where auto-select and filters are well implemented.

## Client defaults decide whether Russian sites survive, and the recommendation list overlaps

The recommended clients are grouped by platform: Shadowrocket and Karing on iOS, Exclave, v2rayNG and Karing on Android, Throne and v2rayN on Windows, and Shadowrocket, Throne and Karing on macOS. The framing is careful, listing applications the author tried personally and was satisfied with, while saying that does not mean you have to use only those. Shadowrocket appears twice, for iOS and for macOS, pointing at the same store listing. The routing warning sits right after this list, and it is the part that decides whether the setup works: some clients, Karing and Hiddify named among them, enable routing rules by default that send Russian sites around the tunnel, so part of the Russian segment that is not on the whitelist can stop working. The advice is to disable those rules or configure them by hand. Selecting a client is therefore also selecting a routing policy you will have to inspect.

## Latency, not ping, is the only signal the text trusts for reachability

The README names one measurement as the main tool for choosing a server during restrictions: the delay check run across the whole subscription at once. It separates that from a TCP or ICMP ping explicitly, saying the first does not reflect whether a server is reachable for a full connection under restrictions while the second may not work at all depending on how the servers are configured. The check appears under different names in different clients, URL Test or Latency Test, but the README says every one of them has it, and that a list of available servers is shown when the run finishes. Most clients can sort by that delay, and the instruction is to connect to the fastest one. What the text never provides is a threshold: there is no number above which a server should be considered unusable, and no guidance on what to do when the whole list comes back slow.

## No license file, no releases, and the primary language recorded as unknown

The project metadata is thinner than the project itself. The license field is empty and no license file appears among the four top level entries, so the terms under which the lists may be redistributed are not stated in the repository, and nothing in the README substitutes for that. The primary language is recorded as unknown even though the documentation is plainly Russian, which suggests the field was populated from file extensions rather than content, since none of the four files has an extension that would identify a language. There are no GitHub releases, so the only history available is the commit log, and the last push on the default branch main is dated 2026-10-03, which for a feed that changes hourly is the only freshness signal a reader gets. The funding section states that the project is fully non-commercial and accepts support through a donation service or in cryptocurrency, and the project contact is the Telegram channel that also serves as the homepage.

## Conclusion

Read zieng2/wl as a data feed with instructions attached, and decide accordingly. It is useful if you already run one of the listed clients and understand that you are importing a list of other people's server configurations, refreshing hourly, with no code to audit and no history beyond the last commit on 2026-10-03. Before you rely on it, check three things. Check that the mirror you picked actually serves a file, since two of the three list files in the repository have no documented mirror address and the experimental mirrors name a fourth. Check what the allow insecure option does in your client before turning it on, because the instructions make it a requirement for the list to be usable. And check the terms yourself: there is no license file and no release history to fall back on.

## FAQ

### What files does the zieng2/wl repository actually contain?

Four entries: README.md, vless.txt, vless_lite.txt and vless_universal.txt. The README is in Russian and is the only documentation file, and there is no client, script or generator code in the listing.

### How often does the zieng2/wl server list change?

The README says the server list is updated once an hour and that all mirrors are updated at the same time. It also says a profile's lifetime can range from several minutes to a full day, since configured servers get blocked as the whitelist situation changes.

### Which clients does zieng2/wl recommend?

Shadowrocket and Karing for iOS, Exclave, v2rayNG and Karing for Android, Throne and v2rayN for Windows, and Shadowrocket, Throne and Karing for macOS. The README presents them as applications the author tried personally, not as a required list.

### Why do some Russian sites stop working after adding a zieng2/wl subscription?

Some clients, Karing and Hiddify among them, enable routing rules by default that send Russian sites around the tunnel. Part of the Russian segment that is not on the whitelist then stops working, and the README advises disabling those rules or configuring them by hand.

### What license applies to the zieng2/wl lists?

No license file appears in the four entry listing and the license field is empty, so the terms are not stated in the repository. The README says the project is fully non-commercial and takes support through a donation service or in cryptocurrency.

### Does zieng2/wl require any setting change inside the client?

The instructions say to enable auto-update for the subscription on roughly the same hourly schedule as the mirrors, and to enable the option translated as allow insecure, which may be global or per subscription. The README states that turning it on increases the number of available servers.

## Sources

- [Official documentation](https://t.me/zieng2)
- [Official README](https://github.com/zieng2/wl#readme)
- [Project repository](https://github.com/zieng2/wl)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zieng2-wl