Start from a clean machine or fresh container with no cache and no personal config, then run six checks: which registry each client uses, that an install succeeds, that a public package arrives through the mirror, that an anonymous request fails, that audit works, and that the network blocks direct access. Each takes minutes.
Why test from a clean state
Your laptop has years of config, caches and credentials. It tells you little about what a new hire or a CI job experiences. A fresh container shows what the documented setup really does.
Check 1: which registry does each client use
Ask every client what it will contact.
npm config get registry
pip config debug
The npm command prints the configured registry. The pip command lists the config files pip checks, which the pip documentation describes as the way to find exact paths. Both should show the mirror, not the public default.
Check 2: does a plain install work
Install one small package in each ecosystem. If it fails with a certificate error, fix trust properly with a certificate authority file and not by switching validation off.
Check 3: did the packages come through the mirror
Open the mirror's access log and look for the requests from your test. If the log shows nothing, the client went elsewhere. This check catches environment variables and stray config files that override your intended setting.
Check 4: is anonymous access refused
Try fetching a package metadata URL with no credentials.
curl -sS -o /dev/null -w "%{http_code}\n" https://mirror.example.internal/repository/npm-group/lodash
Decide in advance what you expect. For a private mirror, a 401 or 403 is the right answer. A 200 means anyone who can reach the host can read your cache and possibly your internal package names.
Check 5: does vulnerability auditing work
Run the audit command in a project with a known vulnerable dependency, as covered in does npm audit work through a mirror. An empty report from a project that should have findings points at a mirror problem.
Check 6: can the build reach the public registry directly
From the same container, try the public registry address. If your design says all installs go through the mirror, network rules should block the direct route, or at least log it. If direct access works, any client with a stray config can bypass the mirror unnoticed.
Record the results
| Check | Expected | Result | Date |
|---|---|---|---|
| Registry setting | Mirror address | ||
| Plain install | Succeeds | ||
| Log entry | Present | ||
| Anonymous request | 401 or 403 | ||
| Audit | Reports known issue | ||
| Direct access | Blocked or logged |
Run the list after each mirror upgrade and after changing CI images. Keep the table with your other operating records.
Where Safeguard fits
Safeguard's continuous monitoring and SBOM scanning cover the packages that end up in your projects, so you can see the outcome of a mirror change. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how monitoring reports a change between scans, the same habit you want for rerunning these checks.
Quick check
How often should we run these checks?
After every mirror upgrade, after CI image changes and at least once a quarter.
What if anonymous access is intentional?
Then document why, limit it to read access and confirm the host is not reachable from the internet.
Sources
Last reviewed: 19 October 2026.
