Iran-v2ray-rules: published geoip, geosite and security rule files for v2ray and xray

Six published data files, and what the README does not say about them

The repository is not a program. It is a set of routing data files, published under the release branch, that a v2ray or xray client downloads and applies. Six files are offered:

https://raw.githubusercontent.com/Chocolate4U/Iran-v2ray-rules/release/geoip.dat

https://raw.githubusercontent.com/Chocolate4U/Iran-v2ray-rules/release/geosite.dat

https://raw.githubusercontent.com/Chocolate4U/Iran-v2ray-rules/release/geoip-lite.dat

https://raw.githubusercontent.com/Chocolate4U/Iran-v2ray-rules/release/geosite-lite.dat

https://raw.githubusercontent.com/Chocolate4U/Iran-v2ray-rules/release/security-ip.dat

https://raw.githubusercontent.com/Chocolate4U/Iran-v2ray-rules/release/security.dat

The naming splits the set along two axes: IP-based versus domain-based data, and a full variant versus a lite variant, plus a separate security pair. The description of the project calls these enhanced and all-in-one geo-location routing files optimized for Iranian users, and the repository topics list adblock, domains, geoip, geosite, gfw, iran, malware, phishing, routing, v2ray and xray. What the project documentation does not cover is the difference between geoip.dat and geoip-lite.dat, or the criteria that decide which entries land in the security files. If that distinction matters to your setup, you have to compare the two files yourself.

GitHub raw links and jsDelivr as the two distribution channels

Every artifact is offered from two places, and the project treats them as peers rather than as a primary and a fallback. The GitHub channel is the raw host for the release branch:

https://raw.githubusercontent.com/Chocolate4U/Iran-v2ray-rules/release/geoip.dat

The jsDelivr channel uses the same branch through its GitHub path form:

https://cdn.jsdelivr.net/gh/chocolate4u/Iran-v2ray-rules@release/geoip.dat

The same pairing is repeated for geosite.dat, geoip-lite.dat, geosite-lite.dat, security-ip.dat and security.dat, so a client that cannot reach one host can be pointed at the other without changing anything else.

A detail that matters more than it looks: the download pages include a QR code image for each file, stored in the assets directory under names such as assets/geoip.png, assets/geosite.png, assets/security.png and matching jsDelivr variants. That is aimed at phones, where pasting a long URL by hand is the annoying part. A Persian translation, README.fa.md, is also linked, which is consistent with a project whose first audience is Iranian users.

One thing the documentation never states is a recommended client setting for update frequency, so a client configured to re-download these files on a schedule is a decision you make on its own.

Wiring the rules into a v2ray or xray client configuration

The usage section gives one instruction: add the following to your v2ray or xray client configuration. The snippet that follows opens an outbounds array and defines a direct outbound tagged for freedom protocol, followed by a block outbound:

"outbounds": [
  {
    "tag": "direct",
    "protocol": "freedom",
    "settings": {}
  },
  {
    "tag": "block",
    "protocol": "black

That is as far as the snippet goes in the published documentation. The block outbound is cut off mid-value, and the routing section that would reference the downloaded .dat files is not shown at all, so the concrete keys your client uses to point at a rule file have to come from your client's own documentation rather than from this repository.

The repository layout does help. Alongside the README files, LICENSE and assets, the tree contains config.json, a scripts directory, a .github directory, and a v2rayN directory, which is the naming used by the v2rayN client for Windows. A config.json and a v2rayN directory suggest ready-made client configuration and a packaged client profile, but the contents of those paths are not described in the README, so treat that as an inference from the layout rather than a documented feature.

Artifacts on a release branch, refreshed by a scheduled workflow

The mechanics of publishing are visible from the repository layout and the release history rather than from a documented build guide. The downloadable files are served from a branch named release, and the header carries a workflow status badge pointing at a release workflow triggered on a schedule. The recent releases are named with a timestamp: 202610191014 dated 2026-10-19, 202610180902 dated 2026-10-18 and 202610160914 dated 2026-10-16. The last push was on 2026-10-22.

Two readings follow. The first is that refresh is a machine activity, since a scheduled workflow and date-stamped releases do not wait for a person to push a new version by hand. The second is that the artifacts are produced by something in the scripts directory, since no other path in the tree plausibly generates a.dat file. The project documentation does not cover that generation step, so the pipeline from source lists to shipped binary is not something you can audit from the published documentation, and the source lists themselves are not part of the repository tree.

For a user, this matters less than it does for a reviewer. A daily refreshed file is convenient, and it is also a binary you did not build, delivered over the same channel as the rest of the repository, changing without a version bump in your client.

Adblocking and security lists sit next to the geo lists

The project description calls out a focus on security and adblocking alongside the geo-location routing, and the topic list confirms it with adblock, malware and phishing among the tags. The file set follows that: security.dat and security-ip.dat are published separately from geosite.dat and geoip.dat, and they are distributed on the same release branch through the same two hosts.

The design choice worth noticing is separation. A user who wants Iranian routing but does not want a malware and phishing list can take the geo files and ignore the security pair, and a client that only supports the standard geographic names can stay on geoip.dat and geosite.dat. The same separation exists for the lite variants, which give users a choice between a smaller and a fuller file without changing how the client references them.

What is missing is any statement of what the security files actually block, how the entries are validated, or how quickly a compromised domain gets removed. A blocklist is a security control, and the documentation here treats it as a data download.

Sing-Box and Clash users are pointed to separate repositories

The introduction does not try to serve every client. For Sing-Box geo-location rules it points to Iran Sing-Box Rules, and for Clash geo-location rules it points to Iran Clash Rules, both under the same maintainer. The same organisation runs three repositories, one per client family, and this one is the v2ray and xray one.

The difference in approach is therefore one of target, not of ambition. The v2ray and xray ecosystem consumes the .dat file format served from a release branch, which is what this repository publishes, while the Sing-Box and Clash clients are served by their own repositories under the same maintainer, so the files you download here are not the ones those clients consume. Nothing in the documentation says the three share a generator, and the fact that all three exist separately under one owner suggests the rule sets are maintained per client rather than derived from a single shared pipeline.

For an adopter, the practical consequence is that picking this repository means picking the v2ray and xray path, and switching client later means switching repository too, not just changing a URL.

GPL-3.0 licensing and a release cadence measured in days

The project is licensed under GPL-3.0, which matters if you redistribute the files inside a product rather than pointing a client at them, though the licence terms themselves are a question for a lawyer rather than for this page. The repository is not archived, and the last push was on 2026-10-22, with three dated releases in the days before that: 2026-10-19, 2026-10-18 and 2026-10-16.

A cadence of roughly a release per day has a clear benefit and a clear cost. The benefit is that domain and IP lists for a filtered network do not go stale, since a blocked domain changes daily in practice. The cost is that your client is silently consuming a different file every time it refreshes, so a routing change you did not make can appear between two restarts, and pinning a known-good state means pinning a dated release such as 202610191014 rather than tracking the release branch.

The project documentation does not cover a changelog, a rollback procedure, or how to verify that a downloaded file is the one the project published, so a daily update is a daily trust decision.

Editorial conclusion

Iran-v2ray-rules suits an Iranian user of v2ray, xray or a compatible client who wants an updated rule set without assembling one, and it is a poor choice for an operator who needs to know how a rule file was produced or who must pin a specific known-good revision. Before pointing a client at the release branch, check the file names your client expects against the six published artifacts, and decide whether a daily refreshed set of opaque binaries is acceptable for your threat model.

Frequently asked questions

Official sources

1. Chocolate4U/Iran-v2ray-rules on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases