scoop-cn replaces every download URL with a Chinese mirror

The problem is a chain of six downloads that each fail

scoop-cn starts from a specific failure pattern rather than a vague complaint about slow networks. The documentation walks through the standard Scoop installation and lists where a user in China can hit a wall. Step one is fetching the Scoop install script from GitHub Raw, which fails. Step two is downloading the Scoop bucket archive and the Main bucket archive, which fail. Step three is fetching 7-Zip from its own website, which is occasionally unreachable, and Git from the GitHub Releases page. Step four is cloning the Main bucket. Step five is checking out the Scoop bucket when updating. Step six is adding further buckets such as extras. The value of enumerating this is that it shows the problem is not one slow download but a dependency chain where each failure blocks the next, and a fix that only handles the first step still leaves you stuck.

One bucket that holds the installer and ten official buckets

The design decision is to bundle rather than to patch. This bucket ships the Scoop install script for first-time installation, and it contains the ten official buckets: main, extras, versions, nirsoft, sysinternals, php, nerd-fonts, nonportable, java and games, the same set you can list with `scoop bucket known`. Putting them in a single bucket means a user searches one place instead of hunting across several, and it is what makes the URL rewriting possible, since the rewriting happens where the manifest lives. The bucket also rewrites application download addresses to domestically reachable mirrors, which is the difference between a bucket that only fixes the install step and one that fixes the applications themselves. The repository layout is minimal and matches the mechanism: a `bucket` directory for the manifests, an `install.ps1` for the installer, an `update.ps1` for the daily refresh, and a `scripts` directory.

Installing Scoop through the proxy

The documented install path runs a single command in a Windows command prompt. It fetches the install script through the proxy and evaluates it directly.

powershell -ExecutionPolicy RemoteSigned -Command "Invoke-RestMethod -Uri https://gh-proxy.org/https://raw.githubusercontent.com/duzyn/scoop-cn/master/install.ps1 | Invoke-Expression"

Two details deserve attention. First, the script is fetched and piped into `Invoke-Expression`, so whatever the URL returns is executed with the permissions of your shell. That is how the official Scoop installer works too, but it means the trust chain runs through the proxy rather than through GitHub, and you are trusting both the proxy and the bucket at once. Second, `RemoteSigned` is the execution policy level for the process, so nothing permanent changes on the machine. After the install, the bucket is refreshed once a day automatically, and the documentation states that the update mechanism is GitHub Actions combined with the proxy, which is why a scheduled workflow badge sits at the top of the README.

When the proxy breaks, you rewrite two URLs by hand

The README is straightforward about the weak point: if the GitHub proxy cannot be reached, which happens from time to time, the bucket cannot update, and you have to change the proxy address. The current value is `https://gh-proxy.org`, and the fix is two commands. The first repoints Scoop's own repository at the proxied official bucket. The second rewrites the origin remote of the cloned main bucket to the proxied copy of this repository.

scoop config scoop_repo https://gh-proxy.org/https://github.com/ScoopInstaller/Scoop.git
git -C "%USERPROFILE%\scoop\buckets\main" remote set-url origin https://gh-proxy.org/https://github.com/duzyn/scoop-cn.git

The second command is the important one to understand. It does not just point the main bucket at this mirror, it points it at the mirror of this mirror, which is how the rewritten application URLs inside the manifests stay in effect after an update. That is also the fragile part: an ordinary `git pull` on the main bucket, or any tooling that resets the remote, can put the original upstream URL back and silently drop the acceleration for every application. The documentation does not describe how to detect that, so it is worth checking the remote after updates.

What the mirror changes, and what it cannot fix

The rewriting is described as replacing download addresses with domestically reachable ones, and the mechanisms behind it are a GitHub proxy service and GitHub Actions. What that buys you is a working path to GitHub-hosted content, which covers the install script, the buckets and any application whose manifest points at a GitHub release. What it does not buy you is immunity from the network. Applications hosted outside GitHub, or on domains that are themselves blocked, are outside the scope of a GitHub proxy, and the 7-Zip download in the chain comes from its own website rather than from GitHub, which is a separate problem the bucket has to address on its own. There is also a trust question that the README does not discuss. Every application you install through this bucket comes from a manifest that a third party maintains and, in some cases, points at a mirror the third party chooses. That is a different trust model from the official buckets, and it is worth knowing before you install an editor or a language runtime this way.

Licence, cadence and who actually maintains it

The repository is MIT licensed, so the bucket itself imposes no obligations on users beyond the notice. The licence, however, says nothing about the licences of the applications whose manifests the bucket rewrites, and those applications carry their own terms that the bucket cannot change. On maintenance, the bucket is refreshed automatically once a day by a scheduled workflow, and the last push was on 2026-10-22, so the automated side of it is current. The human side is narrower: the README credits four contributors by avatar and nothing more, and there are no GitHub releases for the project, so the bucket has no version history to consult. The documentation also does not describe a rollback, a test procedure for the rewritten manifests, or a way to check whether a particular application manifest is still pointing at a live mirror. For a bucket whose whole job is to redirect downloads, that is the part of the documentation you would want most and do not get.

Editorial conclusion

Adopt scoop-cn if you are installing Scoop in mainland China and the GitHub-hosted parts of the standard install fail, and you accept routing every download through a third-party proxy. Do not adopt it if your network already reaches GitHub, or if you cannot audit what a proxy does to your downloads. Before you install, read the install command, because it pipes a remote script straight into Invoke-Expression, and note that updating the proxy address means rewriting the origin remote of the main bucket by hand.

Frequently asked questions

Official sources

1. duzyn/scoop-cn on GitHub
2. Issues
3. License: MIT
4. README