This is happening to us too.
It seems to happen in "bursts" where multiple builds will fail in a row because of network issues.
For example, installing flyway using choco will sometimes result in:
The remote file either doesn't exist, is unauthorized, or is forbidden for url 'https://repo1.maven.org/maven2/org/flywaydb/flyway-commandline/5.2.1/flyway-commandline-5.2.1.zip'. Exception calling "GetResponse" with "0" argument(s): "The remote server returned an error: (403) Forbidden."
Manually reaching the url through a brower is working as expected.
(403) Forbidden is clearly server-side response and unrelated to the networking issue discussed in this topic.
Question is why https://repo1.maven.org returns 403 from time to time. Maybe it is just one of their frontend servers misbehaves and you hit it during those bursts. Or maybe they do not like connections from specific datacenters (builds happened in a few different datacenters). It can be number of other reasons as well.
If you send number of links links to both failed and successful builds, we can try to find some commonalities which can help you to root cause.
But I would also send a request to the maven.org support, because they should know better why this server returns 403.
Builds 22295366 and 22295507 indeed happened in the same network segment in Liquid Web (Lancing, MI) datacenter, behind public IP 220.127.116.11. I tried to download https://repo1.maven.org/maven2/org/flywaydb/flyway-commandline/5.2.1/flyway-commandline-5.2.1.zip from builds behind the same IP and it went fine.
DNS resolution issue happened on VM in AWS West US (Oregon) datacenter. AppVeyor VMs are using Google DNS servers (18.104.22.168 and 10.10.10.10).
Network issues are very difficult to reason about as we cannot control networking end-to-end. However in this case my feeling is that it was issues on the "other side": repo1.maven.org server and on DNS server hosting api.xero.com.
What I would do is to make your code more tolerant to this kind if issues by at least adding retries. For scripting, you can use appveyor-retry utility. For tests (I see you use xunit) you can use https://github.com/giggio/xunit-retry. I would not recommend to add retries everywhere, but at least in places where you see network flakiness.
Also build cache greatly decrease your dependency on external services.