# RoscomVPN Routing: Ready-Made Routing Rules for Happ, INCY, and Mihomo

> This project ships prebuilt routing profiles for three proxy clients, tailored for Russia and Belarus. It bundles custom GeoIP and Geosite lists, but you must verify its maintenance status before relying on it.

**hydraponique/roscomvpn-routing** — Custom routing rules for Happ, INCY, Mihomo with Deeplink

- Repository: https://github.com/hydraponique/roscomvpn-routing
- Website: https://t.me/vpnrouting
- Stars: 2,823 · Forks: 112
- Language: Python
- License: not declared
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/hydraponique-roscomvpn-routing

## What This Project Actually Saves You

RoscomVPN Routing is a collection of prebuilt routing configurations for three proxy clients: Happ, INCY, and Mihomo (Clash Meta and its derivatives). The target audience is users in Russia and Belarus who need a split-tunnel setup: local Russian and Belarusian traffic goes direct, while services like YouTube, Telegram, and GitHub go through a proxy. The README states the goal as 'surgical' filtering, with everything needed unlocked and everything else blocked. If you have ever hand-written rule sets for Clash or similar clients, you know the pain of maintaining GeoIP lists and rule order. This project tries to remove that burden by shipping ready-made profiles. It is not a proxy client itself; it is a set of routing rules that you plug into an existing client. The primary value is the combination of custom GeoIP and Geosite data with a tested rule structure, so you do not have to assemble the pieces yourself.

## The Custom GeoIP and Geosite Mechanism

The routing logic depends on two companion repositories: roscomvpn-geoip and roscomvpn-geosite. The GeoIP file is described as a maximally reduced geoip.dat that contains only a custom list called geoip:direct. That list includes Russian and Belarusian CIDR ranges from three independent geobases: GeoLite2 (MaxMind), IPinfo, and DB-IP. It also adds ranges for 'state-owned' companies like VK Company, Yandex, and CDNVideo, including their foreign assets. Apple Push notification CIDRs are included to fix iOS notification delivery. The interesting part is the DIFF-exclusion step: the project subtracts lists like Re:filter and Antifilter.Network to unblock services that Russian authorities have blocked, and it also excludes foreign CDN services and specific Hetzner and ZeroCDN ranges. This means the GeoIP list is not a simple collection of Russian IPs; it is a curated set that tries to avoid routing blocked or problematic services through the direct path. The Geosite list is similarly optimized and deduplicated for this routing scheme. The result is a routing setup that aims to be both leak-free and functional for the target region.

## Installation: Deeplinks, JSON, and YAML

The README provides several installation methods. For Happ and INCY, there are deeplinks that redirect to a DEFAULT profile, plus separate files for DEFAULT, WHITELIST, and JSONSUB variants. The DEFAULT profile is a full config: RU/BY direct, YouTube/Telegram/GitHub through proxy, and ad blocking. WHITELIST is the opposite: direct only for services and IPs on the Russian whitelist, everything else through proxy. JSONSUB is a minimal profile that only sets DNS and custom geoip/geosite, without built-in rules. For Mihomo, the repository includes YAML templates in the MIHOMO folder: default.yaml for manual addition with 40+ rule providers, and template_remnawave.yaml for integration with the Remnawave panel. The README says to substitute your subscription URL and use it with any Mihomo-compatible client. The deeplinks are text files that likely contain a URI scheme, but the exact format is not shown in the provided material. You would open these links on your device to import the config. The JSON files are the actual routing configs, and the YAML files are for manual setup. The installation is not a single command; it depends on the client and the method you choose.

## The Whitelist vs. Default Trade-off

The two main profile types represent different philosophies. The DEFAULT profile routes only specific foreign services through the proxy, keeping everything else direct. This is efficient for users who primarily access Russian sites and want to avoid proxy overhead for local traffic. The WHITELIST profile inverts that: only whitelisted Russian services and IPs go direct, and all other traffic goes through the proxy. This is a safer choice if you want to ensure that no traffic leaks outside the proxy except for explicitly allowed services. The trade-off is performance and latency. With DEFAULT, you might accidentally send a blocked service through the direct path if it is not in the custom lists. With WHITELIST, you might route a local service through the proxy unnecessarily, slowing it down. The README claims the DIFF-exclusion process handles many edge cases, but it cannot cover every service. Users who need strict privacy or who access a wide range of foreign sites might prefer WHITELIST, while those who value speed for local browsing might prefer DEFAULT. The choice is not trivial, and the project does not provide guidance on which profile suits which use case.

## A Genuine Limitation: The Unknown Maintenance and License

The repository metadata shows no recent release, no archived flag, but also no last push date. The license is listed as unknown. This is a red flag for production use. The README describes an elaborate build process with multiple external lists (Re:filter, Antifilter.Network, CDN-RuleSet), which means the GeoIP and Geosite data must be regenerated frequently to stay accurate. If the maintainer stops updating, the lists will drift from reality, and routing will start to leak or block incorrectly. The absence of a license means you cannot legally reuse or modify the configs without asking permission. For an individual user, this might be acceptable, but for a company or a project that wants to fork or redistribute, it is a problem. The README also does not mention any versioning or changelog, so you cannot track what changed between updates. Before adopting this, you should check the commit history on GitHub and see if the maintainer is active. The deeplinks might also break if the repository is renamed or deleted. This is a real operational risk.

## Alternative Approach: Hand-Built Rules or Other Rule Providers

The main alternative is to build your own routing rules using standard GeoIP and Geosite databases from sources like the GeoLite2 free database or the v2ray/domain-list-community. The difference in approach is that those sources are general-purpose and maintained by large communities. You would write your own rule order in a Clash or Mihomo config, deciding which domains and IPs go direct and which go through the proxy. This gives you full control but requires ongoing maintenance. Another alternative is to use rule providers like the ones from the Loyalsoldier or the Anti-AD project, which offer prebuilt rule sets that you can subscribe to. Those are updated regularly and are often more transparent about their maintenance. The trade-off is that they are not tailored to the Russian/Belarusian context, so you would need to add your own RU/BY direct rules. RoscomVPN Routing tries to combine the convenience of prebuilt rules with regional specificity, but it sacrifices the transparency and community support of the larger projects. If you need a quick start and trust the maintainer, this project is convenient. If you need long-term reliability, a hand-built config with established rule providers might be safer.

## What to Verify Before You Rely on It

The README gives you a clear checklist of what to check before trusting this project. First, confirm the custom GeoIP and Geosite repositories are still active and updated. The entire routing logic depends on them. Second, test the deeplinks on your actual device, because the redirect service (routing.help) might be down or changed. The README says the deeplinks are text files, so you can open them to see the target URI. Third, inspect the JSON or YAML files to ensure they match your proxy subscription. The Mihomo template requires you to substitute your subscription URL, and if you do it wrong, the config will not work. Fourth, check the DIFF-exclusion lists. The README mentions Re:filter and Antifilter.Network, but you should verify that those lists are still being maintained and that they do not conflict with your own needs. Finally, check the repository's commit history for recency. The last push date is not shown in the metadata, so you must look at the GitHub page directly. Without an active maintainer, the routing rules will become stale, and the project will lose its value. These are concrete steps, not generic advice, because they are tied to the specific files and services the project uses.

## Conclusion

Adopt RoscomVPN Routing if you use Happ, INCY, or Mihomo in Russia or Belarus and want a preassembled routing setup that keeps local traffic direct while proxying foreign services. Do not adopt it if you need active maintenance guarantees, a declared license, or support for other regions. Before use, verify the last commit date, test the deeplinks, and inspect the JSON or YAML files against your own proxy subscription. The project's value depends entirely on its lists staying current, so check the repository for recent updates before trusting it in production.

## FAQ

### What is RoscomVPN Routing, and which clients does it support?

It is a set of ready-made routing configurations for Happ, INCY and Mihomo, the last covering Clash Meta and Clash Mi among others, aimed at traffic from Russia and Belarus. The rules sit in the HAPP, INCY and MIHOMO folders, while the GeoIP and Geosite data they reference live in two separate sibling repositories.

### How do the DEFAULT, WHITELIST and JSONSUB profiles differ in RoscomVPN Routing?

DEFAULT is the full profile: RU and BY direct, YouTube, Telegram and GitHub through the proxy, advertising blocked. WHITELIST goes direct only for services and IP ranges on Russian white lists and proxies everything else. JSONSUB is the minimal one, DNS plus the custom geoip and geosite entries with no built-in rules.

### Can I pin a version of RoscomVPN Routing?

No. The project has never cut a GitHub release, so there is no tag to pin to, and the last push to main was 2026-09-29. Each DEFAULT, WHITELIST or JSONSUB file has to be judged at whatever commit last touched it.

### What licence covers the RoscomVPN Routing configuration files?

None is recorded, and no LICENSE file sits at the root of the tree. That matters because the rules are produced by removing entries from lists published by Re:filter, Antifilter and a third-party CDN rule set, and those upstream terms are the ones a redistributor has to read.

### What does excluding 0.0.0.0/8 from the private list do in RoscomVPN Routing?

It is listed among the differences applied to the GeoIP data, and the text gives the reason as preventing a DNS leak on some devices. The same list also keeps the CIDR ranges Apple uses for push notifications, which it says solves notification delivery problems on iOS devices.

## Sources

- [Official documentation](https://t.me/vpnrouting)
- [Official README](https://github.com/hydraponique/roscomvpn-routing#readme)
- [Project repository](https://github.com/hydraponique/roscomvpn-routing)

---

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