Google Antigravity is one of the more interesting AI coding environments available today, bringing multiple AI model families into a single development workflow. That design makes a particularly confusing failure mode stand out: Claude and GPT continue working, authentication succeeds, the server has normal internet connectivity — yet Gemini suddenly returns an HTTP 400 error stating that the user’s location is not supported.
This is especially disorienting when Antigravity runs over SSH on a remote Linux VPS, an increasingly common setup for developers who keep their coding agents on a dedicated server rather than a local machine.
A representative case involves a cloud VPS hosted in one country, operated remotely by a developer physically located in another. Gemini models stop responding, returning:
HTTP 400 Bad Request
{
"error": {
"code": 400,
"message": "User location is not supported for the API use.",
"status": "FAILED_PRECONDITION"
}
}
Claude and GPT models, running through the very same Antigravity session, continue to work without interruption.
After testing DNS, IPv4, IPv6, the Google Cloud Code endpoint, public IP geolocation, and IPv6 firewall routing, the evidence points toward a much more specific problem: Google’s Gemini/Antigravity backend can reject requests based on the network egress IP or hosting environment, even when that IP is located in a country where Gemini is otherwise supported.
This article explains what’s happening, how to diagnose it, and what you should — and shouldn’t — change on your server.
The exact Antigravity error
The error itself looks like this:
Error: HTTP 400 Bad Request
{
"error": {
"code": 400,
"message": "User location is not supported for the API use.",
"status": "FAILED_PRECONDITION"
}
}
There may also be a Google-side Trace ID and Cloud Code headers in the response, along with a trajectory ID unique to that session.
One important detail: this is not an authentication error. Antigravity can successfully authenticate your Google account and still have Gemini requests rejected afterward. That distinction matters enormously when troubleshooting.
The most confusing symptom: Claude and GPT work
The most useful diagnostic clue is often the model-specific behavior:
| Component | Result |
|---|---|
| Antigravity authentication | Works |
| SSH connection | Works |
| Internet connectivity | Works |
| Claude | Works |
| GPT / Codex | Works |
| Gemini | Fails |
| Google Cloud Code endpoint | Reachable |
| DNS | Works |
That pattern points away from a general server failure. It also makes a broken Google login, expired credentials, or a fully unsupported account much less likely.
A similar pattern has been documented across the Antigravity community: users have reported Gemini failing from one VPS or public IP while the same Google account works from another VPS, with Claude and GPT-OSS remaining functional on the failing machine. (GitHub)
Why this error is misleading
The phrase
User location is not supported for the API use.
sounds as though Google is simply checking the country where the person is physically located. That interpretation is often too simplistic when Antigravity is running remotely.
When an AI coding agent runs on a VPS, the architecture looks more like this:
Developer's local machine (Region A)
│
│ SSH
▼
Cloud VPS (Region B)
│
│ HTTPS
▼
Google Cloud Code / Gemini
The Gemini request therefore originates from the VPS’s network environment. In other words, the “location” that matters can be the request’s egress network, rather than the physical location of the person sitting at the keyboard.
Recent reports strongly suggest that Gemini requests through Antigravity can be rejected based on the egress region/IP or hosting network, including datacenter IP ranges specifically. One investigation found that requests from a datacenter egress were rejected, while routing the same credential through a different, supported egress resulted in a 200 OK. (GitHub)
A VPS being in a supported country does not necessarily solve the problem
This is the subtle part.
Consider a representative example:
IPv4: 203.0.113.45 (example address)
City: Warsaw
Region: Mazovia
Country: Poland
Organization: Example Datacenter Provider
The IP geolocation here is entirely reasonable — Poland is a country where Gemini is generally supported. Yet in documented cases, Gemini still returns the location-restriction error despite this.
That suggests this is not necessarily a simple:
Is Poland supported?
check. It may instead be closer to:
Is this request coming from an egress/network
that the Gemini service accepts for this API?
Recent issue reports describe this as an egress-region or datacenter-IP restriction, occurring even when the IP itself geolocates to a country that would normally be supported. (GitHub)
The role of hosting providers
This does not mean any single provider is universally blocked. It means that hosting-provider IP ranges can behave differently from residential or consumer internet addresses, because a cloud server typically has:
- a datacenter ASN,
- public IP ranges shared across many customers,
- an IP reputation/history distinct from a residential ISP,
- geolocation data that doesn’t perfectly align with Google’s own network classification.
Recent Antigravity reports have involved multiple cloud and VPS providers, not one specific company. One report describes a Leaseweb VPS where Gemini failed while another VPS on Hostinger worked fine with the same Google AI Pro account. The author tested DNS, TLS, IPv4, IPv6, disabling IPv6, and reauthentication, leaving the public IP and its associated location as the major differentiator. (GitHub)
That’s one of the strongest pieces of evidence that this is a network-egress problem, not a normal Antigravity installation issue.
Checking your VPS’s public IP
Before changing anything, check what the outside world sees.
For IPv4:
curl -4 https://api.ipify.org
echo
For IPv6:
curl -6 https://api64.ipify.org
echo
Then check the IP’s geolocation:
curl -4 https://ipinfo.io/json
This returns the geolocation data associated with your egress IP — city, region, country, and hosting organization.
The important thing is to establish both:
- What public IP the server is actually using
- How that IP is being geolocated
Do not assume that the country shown by your cloud provider is necessarily the classification Google is using.
Checking the Google Cloud Code endpoint
Another useful test is to verify that the Google endpoint itself is reachable. Antigravity uses Google’s Cloud Code infrastructure, including:
daily-cloudcode-pa.googleapis.com
Test the hostname with:
curl -4 -I https://daily-cloudcode-pa.googleapis.com
and:
curl -6 -I https://daily-cloudcode-pa.googleapis.com
A successful connection may still return:
HTTP/2 404
That is not automatically a problem — a bare request to an API hostname is not the same as a valid Cloud Code API operation. What matters for this diagnostic is whether the network connection itself succeeds.
In testing across multiple affected environments, both IPv4 and IPv6 have reliably established HTTPS connections to the endpoint even while Gemini itself continues to reject requests. That eliminates the simplest explanation — “Google is unreachable from the VPS.”
DNS and IPv6 testing
You can confirm which IPv6 addresses Google publishes for the Cloud Code endpoint:
dig AAAA daily-cloudcode-pa.googleapis.com
A typical response contains several Google IPv6 addresses in the 2001:4860::/32 space.
Then test an IPv6 connection:
curl -6 -v https://daily-cloudcode-pa.googleapis.com \
2>&1 | grep -E "Connected|Trying|IPv6"
and the equivalent IPv4 connection:
curl -4 -v https://daily-cloudcode-pa.googleapis.com \
2>&1 | grep -E "Connected|Trying|IPv4"
If both work, you’ve established that DNS resolution, IPv4 connectivity, and IPv6 connectivity are all functioning, and the endpoint itself is reachable. That eliminates another whole category of troubleshooting.
Could IPv6 be responsible?
Possibly. A notable Google AI Developers Forum report involving Antigravity over SSH describes a user solving the same error by blocking IPv6 traffic specifically to Google’s IPv6 ranges, without disabling IPv6 on the whole production server:
sudo ip6tables -A OUTPUT \
-d 2001:4860:4000::/36 \
-j REJECT \
--reject-with icmp6-port-unreachable
sudo ip6tables -A OUTPUT \
-d 2a00:1450:4000::/36 \
-j REJECT \
--reject-with icmp6-port-unreachable
The user specifically noted that disabling IPv6 for the entire production server was not acceptable. (Google AI Developers Forum)
You do not necessarily need to disable IPv6 globally just to test this theory.
A controlled IPv6 test
If your web sites depend on IPv6, a global change such as:
net.ipv6.conf.all.disable_ipv6=1
is a poor troubleshooting choice. A narrower firewall test is safer.
After adding the Google-specific rules above, inspect them:
sudo ip6tables -L OUTPUT -n -v
You should see something like:
REJECT ... 2001:4860:4000::/36
REJECT ... 2a00:1450:4000::/36
The packet counters here are the useful part. If those rules remain at:
0 packets
0 bytes
while Gemini continues failing, that’s evidence the Antigravity request isn’t being fixed by blocking those IPv6 destinations at all — meaning Gemini traffic isn’t actually routing over IPv6 to begin with. In documented cases, this is exactly the outcome: the rules install cleanly, Antigravity is restarted, Gemini is tested again, and the counters stay at zero while the original error persists.
What the IPv6 test really tells you
It’s important not to overinterpret this result. If you block Google’s IPv6 ranges and Gemini still fails, it doesn’t prove IPv6 is irrelevant in every environment. It means:
For this particular server and this particular failure, blocking those Google IPv6 ranges did not resolve the problem.
That distinction prevents turning one environment’s result into a universal rule.
A more likely explanation: egress IP classification
The current evidence increasingly points here. One detailed investigation compared requests that differed only in their network egress:
- native datacenter/hosting IP →
400 User location is not supported - different-region proxy/edge or residential egress →
200 OK
That report specifically concluded that the discriminator was the egress region/IP, not the request body — and it noted that Claude and Codex are unaffected because they don’t hit the same Gemini regional gate. (GitHub)
That explanation fits the otherwise bizarre combination perfectly:
Same account
Same Antigravity
Same machine
Same authentication
Claude → works
GPT/Codex → works
Gemini → fails
If the Google account itself were invalid, this model-specific behavior would be much harder to explain.
Why your physical location may not match the egress location
Consider a common scenario: a developer physically located in one country connects over SSH to a VPS hosted in a different country. Antigravity, running entirely on the remote server, effectively operates within that server’s network environment — not the developer’s home network.
Developer's physical location
│
│ SSH
▼
Cloud VPS (hosting provider network)
│
│ HTTPS
▼
Google Cloud Code / Gemini
The developer’s local ISP address is not necessarily the address seen by the Gemini service for the agent request. This is one reason remote development environments can behave differently from a locally installed Antigravity client — a local install typically uses the developer’s ordinary internet connection, while an SSH-based setup causes the model request to originate from the remote server instead.
Why reinstalling Antigravity often doesn’t help
This error can tempt people into a long list of ineffective fixes:
Reinstall Antigravity
Delete credentials
Log in again
Delete ~/.gemini
Restart the server
Change Google account
Change Google country
Reinstall Node.js
Flush DNS
Some of these are reasonable generic troubleshooting steps, but current evidence suggests they’re often irrelevant when the failure is egress-specific. One current issue report describes a user who had already tested reinstallation, deleted the Gemini configuration, reauthenticated, and checked DNS, TLS, IPv4, IPv6, disabled IPv6, and removed VPN routing — yet the same Google account worked on another VPS and failed on the original one. (GitHub)
That is an extremely useful troubleshooting pattern to replicate.
How to tell whether you have the same problem
You have a strong case for an egress-related restriction when all of the following are true:
- Authentication works — you can sign into Antigravity normally.
- Non-Gemini models work — Claude and/or GPT-based models are functional.
- Gemini alone fails with
FAILED_PRECONDITION: User location is not supported for the API use. - The VPS can reach Google — IPv4 and/or IPv6 HTTPS connections succeed.
- The same account works elsewhere — this is perhaps the strongest diagnostic test. Run the same account from a different network or VPS. If Gemini suddenly works, the problem is much more likely to be associated with the original egress. Recent issue reports show exactly this pattern. (GitHub)
What not to do
Don’t change your Google account’s country just because of this error. A datacenter egress restriction can produce this message even when the user and IP appear to be located in a supported country. Changing the account region may accomplish nothing.
Don’t immediately migrate your entire VPS. Moving your production server is a large change when the problem may involve only one outbound API.
Don’t disable IPv6 globally if your sites need it. There are more targeted diagnostic options, covered above.
Don’t assume a successful curl proves Gemini should work. A successful request to daily-cloudcode-pa.googleapis.com only proves your server can establish an HTTPS connection to that hostname — it doesn’t reproduce Antigravity’s authenticated Cloud Code request.
Possible workarounds
There’s no single universal fix yet, but the evidence suggests several practical options.
Option 1: Try a different public IPv4
This is one of the cleanest experiments. If your VPS provider allows swapping or adding a public address, and Gemini immediately begins working on the new one, you have strong evidence that the original IP or subnet classification is the issue — preferable to changing the entire application stack.
Option 2: Use a different egress only for Gemini
This is potentially the best architecture for production servers. Instead of routing the entire VPS through a VPN, the goal is to route only model traffic through an alternate path:
┌── Websites
│
Production VPS ──────────┤── Mail
│
└── Normal server traffic
Antigravity
│
▼
Alternate egress
│
▼
Gemini
One current investigation explicitly describes routing the affected Antigravity credential through a supported-region proxy as a working solution. (GitHub)
Option 3: Use a per-process or per-service proxy
If the Antigravity remote agent can be isolated, you may be able to apply a proxy to that process specifically, rather than changing global system networking — much more attractive on a production VPS.
Option 4: Move the Antigravity execution environment
If everything else on the VPS is production-critical and you’d rather not introduce special routing, another option is running Antigravity on a separate machine whose egress is accepted by Gemini:
Production VPS
│
└── websites, databases, mail
Developer machine / secondary VPS
│
└── Antigravity + Gemini
Less elegant, but operationally simple.
A particularly important clue about newer Gemini models
There are also reports involving the newer Gemini 3.1 and 3.5 families where the same FAILED_PRECONDITION error appears even when other Antigravity model paths work. (GitHub)
That means users shouldn’t automatically assume “Gemini used to work, therefore my current network must still be accepted.” Google can change regional enforcement, model availability, and backend routing independently of local configuration — one reason the problem can appear to arrive “suddenly.”
What this means for Antigravity users in 2026
The broader lesson is that AI coding environments are increasingly dependent on server-side regional policy, not just local application configuration. Antigravity is not a self-contained model runtime. A request may pass through:
Antigravity
↓
authentication
↓
Cloud Code
↓
Gemini backend
↓
regional / egress validation
↓
model execution
A failure anywhere in that chain can surface as one unhelpful sentence: “User location is not supported for the API use.” That message doesn’t necessarily mean “you are personally in an unsupported country.” It’s closer to: “the network this request is arriving from is not currently accepted for this API.” That difference is crucial for troubleshooting effectively.
A practical troubleshooting checklist
When Gemini suddenly stops working in Antigravity on a VPS, work through this order:
# 1. Check your public IPv4
curl -4 https://api.ipify.org
echo
# 2. Check your public IPv6
curl -6 https://api64.ipify.org
echo
# 3. Check IPv4 geolocation
curl -4 https://ipinfo.io/json
# 4. Check Google Cloud Code DNS
dig AAAA daily-cloudcode-pa.googleapis.com
# 5. Check IPv4 connectivity
curl -4 -v https://daily-cloudcode-pa.googleapis.com
# 6. Check IPv6 connectivity
curl -6 -v https://daily-cloudcode-pa.googleapis.com
Then test the key question: does the same Google account work from another network or VPS? If yes, stop reinstalling Antigravity and investigate the egress IP/network instead.
Case summary: connecting the evidence
Bringing the diagnostic threads together, a typical affected environment shows this pattern:
Developer's physical location: Region A
Antigravity execution environment: Cloud VPS
VPS country: Region B (generally supported by Gemini)
IPv4 geolocation: Matches Region B
IPv4 connectivity to Google: Works
IPv6 connectivity to Google: Works
Authentication: Works
Claude: Works
GPT: Works
Gemini: Fails
Testing Google’s IPv6 ranges via targeted ip6tables rules — blocking 2001:4860:4000::/36 and 2a00:1450:4000::/36 specifically, rather than disabling IPv6 system-wide — is a useful next diagnostic step. In documented cases, these rules install successfully, but their packet counters remain at zero while Gemini continues to return the same 400 error. That outcome makes a pure IPv6 explanation unlikely.
The remaining evidence points much more strongly toward Google’s Gemini backend rejecting the VPS/datacenter egress path specifically, independent of the account holder’s actual location or the VPS’s geolocated country.
This conclusion is consistent with the broader pattern documented across current Antigravity reports: identical credentials can work from one VPS while Gemini fails from another, even as Claude and GPT continue functioning normally on the affected machine. (GitHub)
The good news
This does not necessarily mean your server is broken. Your websites, IPv6, Nginx, PHP, databases, SSH, general Google connectivity, and other AI models can all continue functioning normally. The problem can be isolated to the network egress used for Gemini specifically — a much smaller problem than it initially appears.
FAQ
Is my Google account banned or restricted? No. This error is separate from authentication and account standing. Antigravity can authenticate successfully and still have Gemini requests rejected on a per-request regional basis.
Do I need to migrate my entire VPS to fix this? Not necessarily. In many documented cases, the fix is as narrow as assigning a different public IP or routing only Gemini traffic through an alternate egress, rather than moving the whole server.
Does this affect Claude or GPT models running inside Antigravity? Current reports indicate the restriction is scoped to Gemini’s regional/egress validation and does not affect Claude or GPT/Codex requests routed through the same Antigravity session.
Will Google eventually fix this? Unclear. Regional enforcement is controlled entirely on Google’s backend and can change without notice — a network egress that works today isn’t guaranteed to remain accepted indefinitely.
Final takeaway
If you see:
HTTP 400
FAILED_PRECONDITION
User location is not supported for the API use.
in Antigravity — especially when Antigravity runs over SSH on a VPS, Claude works, GPT works, and Gemini alone fails — don’t immediately assume your Google account or physical location is the problem.
Check the server’s public IP, test Google’s Cloud Code endpoint over IPv4 and IPv6, compare behavior from another network, and investigate the egress IP/hosting network before making invasive changes. For production VPS users, the eventual fix may be as simple as assigning a different public IP, or routing only Antigravity/Gemini traffic through a different accepted egress, rather than moving the entire server.
Google’s own regional handling can also change over time, so a VPS that worked previously is not guaranteed to remain accepted indefinitely. (GitHub)
