QuantumultX-Rewrite: a hosted collection of QX rewrite configs

What QuantumultX-Rewrite actually is: a URL index, not a program

The repository has three top-level entries: README.md, rewrite/, and rule/. The README is a table of named rewrites with a link column, and nearly every link points at yfamilys.com, the author's own site, rather than at raw files inside the repository. So the thing you install is a hosted .conf file, and the repository is the catalogue that tells you which ones exist.

The names in that catalogue describe intent, not mechanism: 去广告 (ad removal), 去广告mix, 去广告mix+, 禁用iOS更新 (disable iOS updates), 奈飞评分 (Netflix ratings), 历史价格 (price history), 代理链路检测 (proxy chain check), plus a long list of per-app entries such as WPS, Spotify, CamScanner, VSCO and Bilibili 1080P. The README does not explain what any single file matches or which scripts it loads, so the name is all you get before you fetch it.

The intended reader is someone already running Quantumult X on iOS who wants a rewrite without writing one. It is not a library you import, and there is nothing here for Android, despite the search phrasing people use.

How a QX rewrite config works and where the scripts live

A Quantumult X rewrite is a text config that Quantumult X evaluates as HTTPS traffic passes through its local proxy. The repository's own files are the clearest evidence of the shape: the top-level rewrite/ directory holds the configs, and the primary language of the repository is JavaScript, which is what the scripts inside those configs are written in.

That gives a three-part data flow. The client app makes an HTTPS request; Quantumult X matches its URL against rules in the .conf file; when a rule matches, Quantumult X either rewrites the response body directly or runs a JavaScript script that returns a modified body. The .conf file is the wiring, the JavaScript is the logic, and the rule/ directory in this repository holds the routing rules that decide which traffic goes where.

The practical consequence is that a rewrite config is not sandboxed by anything in this repository. A file you add can read and modify the response of every hostname it matches, and the JavaScript it loads can do the same. The README gives no per-file description of hostnames or scripts, so the only way to know what a config touches is to open the .conf URL and read it.

Installing a QuantumultX-Rewrite config in Quantumult X

There is no package manager step. The README's link column is the install path: you take a .conf URL from the table and add it inside Quantumult X. The one URL the README gives verbatim, for disabling iOS updates, is https://yfamilys.com/rewrite/DisableUpdate.conf.

In Quantumult X, open the rewrite section of the settings and add a remote rewrite resource by URL. The exact menu labels are Quantumult X's, not this repository's, and the README does not reproduce them, so treat the following as the shape of the step rather than a transcript:

Rewrite > 引用 (remote resource) > add
https://yfamilys.com/rewrite/DisableUpdate.conf

After adding it, reload the profile and check that the entry appears in the rewrite list. Then open the .conf URL in a browser before trusting it: the file is plain text, and its [rewrite_local] or [mitm] sections name the hostnames it will intercept. If a hostname you care about is listed under MITM, Quantumult X will decrypt that traffic.

The README also offers an aggregated file at https://yfamilys.com/rewrite/4in1.conf, described there as 重写合集 (rewrite collection). Adding one URL is easier than adding forty, but it also means one file decides everything, and the README does not say which of the individual configs it contains or in what order they apply.

The MITM dependency, and what breaks when a config is wrong

Every rewrite here depends on Quantumult X's HTTPS decryption. That is the real constraint: if a hostname is not covered by an enabled certificate and a matching MITM entry, the rewrite silently does nothing. There is no error surfaced in the app for an unmatched rule, and the README documents no troubleshooting path for it.

A second failure mode is staleness. These configs match against the response format of specific app versions. When an app changes its API, a rewrite that unlocked a feature or stripped an ad stops matching, and the symptom is identical to the MITM case: nothing happens. The repository has no releases, so there is no changelog to check which configs were touched when. The last push to master was on 2026-09-23, which tells you the tree is current but not which file changed.

Third, wrong-tool territory. If you want to block ads system-wide rather than per-app, or if you are not on iOS, this is the wrong layer. And if a config depends on a hostname you also route through a different proxy policy, the rewrite and the routing can disagree about which request they are looking at.

How this differs from a self-written rewrite or a rule-only setup

The alternative most users weigh is writing the rewrite themselves. A hand-written .conf is a few lines: a URL pattern, a match condition, and either a replacement body or a script reference. The difference is not capability, since Quantumult X runs both identically. It is provenance and control. A self-written file matches exactly the hostnames you chose and you can read every line because you wrote it. A file from this repository is a black box until you open it, and it is hosted on a domain the author controls, so the content behind a stable URL can change without the repository changing.

The other alternative is a rule-only configuration, which is what the repository's own rule/ directory holds. Rules decide routing; rewrites modify content. If your actual problem is that traffic goes to the wrong proxy, a rewrite config will not fix it, and adding one only increases the number of things intercepting your HTTPS sessions. People comparing this project with other rewrite collections should compare on that axis: how many hostnames each one decrypts, and whether the configs are versioned.

Maintenance, licence and the cost of keeping it working

The repository is not archived and the last push was on 2026-09-23, so the tree is being touched. That is the only maintenance signal available: there are no releases, and the README has no changelog section, so you cannot tell from the repository which individual config was updated or why. Upgrading, in practice, means re-fetching the same URL and hoping the change is an improvement. Because the files are served from yfamilys.com rather than from raw.githubusercontent.com, there is no commit hash to pin to and no diff to review.

The licence field is unknown, and the repository has no licence file among its top-level entries. Without a stated licence, the default position is that the author keeps their rights, so redistribution or bundling these configs into your own product is not something the repository grants you. This is a description of what the repository states, not legal advice; if you plan to redistribute, ask the author.

On the cost side, the honest accounting is that each config you add is another set of hostnames going through MITM, and each one is a small ongoing liability when the target app ships an update. The aggregate 4in1.conf multiplies that liability by however many configs it merges.

Editorial conclusion

Adopt this if you already run Quantumult X on iOS and want a ready-made URL for a specific rewrite, such as the disable-iOS-update config, rather than writing your own. Do not adopt it if you need a documented licence, a pinned version, or support for anything other than Quantumult X; the repository has no releases and no licence file. Before adding any URL, open it in a browser and read the hostnames it matches and the scripts it loads, because the README itself documents none of that.

Frequently asked questions

Official sources

1. deezertidal/QuantumultX-Rewrite on GitHub
2. Issues
3. Project website
4. README