No. Maven's documentation says there can be at most one mirror for a given repository, that it will not aggregate mirrors with the same mirrorOf value, and that it simply picks the first match. For failover, put a repository manager behind one URL or switch settings files in CI.
What the documentation says
The Maven mirror guide describes a mirror as an alternative location for a repository, configured in the user settings file. It gives reasons to use one: a geographically closer copy, your own internal repository, or a local cache in front of Central. Then it states the limit plainly: you cannot map one repository to a group of mirrors that all define the same mirrorOf value. Maven does not merge them and uses the first match. If you want a combined view of several repositories, the guide says to use a repository manager.
The guide also warns about public mirror lists. It says the mirrors listed in repository metadata may not have the same contents and are not supported.
What this means for CI
A second mirror entry for the same repository does nothing useful during an outage. Maven will not try it. A build with a dead first mirror fails, even though a healthy second one is configured two lines below.
Here is the shape that does not work.
<mirrors>
<mirror>
<id>primary</id>
<url>https://primary.example.internal/maven</url>
<mirrorOf>central</mirrorOf>
</mirror>
<mirror>
<id>secondary</id>
<url>https://secondary.example.internal/maven</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
Three ways to get failover
- One stable URL in front of two backends. Run a repository manager or a load balancer so the mirror URL stays fixed while the instances behind it change. Maven sees one mirror, and you handle health checks outside it. This is the cleanest option.
- Two settings files, chosen by the pipeline. Keep a normal file and a recovery file. A pipeline variable selects which one the job uses. It is manual, but it is visible in the job log and easy to audit. The idea matches the job level fallback in should CI fall back to the public registry.
- A warm local repository. Keep a restored copy of the local repository on the runner so most artifacts resolve without the network. Maven also has an offline flag for this case. Rehearse it with the monthly offline build drill.
Check your wildcard
Failover design is wasted if the mirror pattern is wrong. A mirrorOf wildcard that is too broad can send repositories you did not intend through your mirror, and a stray space can break it silently. See mirrorOf wildcards and the whitespace trap. Also read why a caching proxy beats a full copy for a Central mirror.
Test it
Block the primary in a test pipeline and run a clean build. If it fails, you have learned that your failover is a belief and not a feature. Fix it before the next incident, and record the time to recover.
Where Safeguard fits
Whatever mirror layout you choose, the builds still pull real artifacts into your product. Safeguard's SBOM and dependency scanning lists the artifacts each build used, and reachability analysis helps you decide which flagged ones matter first.
Quick check
Does listing two mirrors with the same mirrorOf help?
No. Maven uses the first match and does not aggregate them, so the second entry is never tried during an outage.
What is the simplest reliable setup?
One stable mirror URL in the settings file, with a repository manager or load balancer behind it that has more than one healthy backend.
Sources
Last reviewed: 19 October 2026.
