Issue connecting Antigravity from Alibaba Cloud (Mainland China) via Shadowsocks Proxy

[wchengjia]

Hi everyone,

I'm trying to run Antigravity on an Alibaba Cloud (ECS) server located in mainland China. To bypass network restrictions, I have set up a Shadowsocks client on the server, which connects to a proxy node in Singapore.

The Setup:

Server: Alibaba Cloud ECS (Mainland China).

Proxy: Shadowsocks client running locally on the server, forwarding traffic to a Singapore server.

Verification: curl and other CLI tools confirm that the server can access external networks (like Google/Gemini API) via the proxy.

The Problem:

Despite the proxy being active and the network appearing "connected," Antigravity consistently fails at the final step of the connection/authentication process. It gets stuck during verification and never completes the handshake, making the server unusable within the Antigravity interface.

Questions:

Does Antigravity's authentication or agent-to-client communication use specific ports or protocols that might be bypassing standard SOCKS5 or HTTP proxy environment variables?

Has anyone successfully deployed Antigravity on a firewalled server using a proxy? If so, did you need to use a specific MCP (Model Context Protocol) configuration or a transparent proxy (like TPROXY or tun2socks) to ensure all traffic is captured?

Are there any logs I can check to see exactly where the verification is hanging?

I’m currently focusing on building an IELTS teaching application and need this remote environment to work for my dev workflow. Any advice would be greatly appreciated!

[SHEWALERUSHI]

It sounds like the proxy itself is working (since curl can reach external services), which suggests the issue may be related to how Antigravity establishes its authentication or persistent connection rather than basic HTTP traffic.

Some tools bypass standard HTTP_PROXY / HTTPS_PROXY variables and instead use:

direct TCP/WebSocket connections

gRPC or custom protocols

background agent services that ignore environment proxy settings

Because of this, the final handshake step can fail even when normal CLI traffic works.

1. Verify proxy environment variables are visible to the agent
   Make sure the Antigravity process inherits proxy variables:

echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $ALL_PROXY

If Antigravity runs as a service, define them globally:

export ALL_PROXY=socks5://127.0.0.1:1080

2. Check if WebSocket or gRPC traffic bypasses SOCKS
   Some agents open raw outbound connections. In this case, a transparent proxy works better than a client-only proxy.

Possible solutions:

tun2socks

TPROXY-based routing

system-level routing through the proxy interface

These ensure all outbound traffic is captured, not only HTTP requests.

3. Inspect logs
   Try checking:

~/.config/antigravity/

or

~/.local/share/antigravity/

Also run the agent with verbose/debug mode if available:

antigravity --debug

Handshake failures usually appear as TLS or connection timeout errors.

4. Firewall / region restrictions
   Since the server is in mainland China, the verification step may require endpoints blocked by default routing. Testing connectivity to Antigravity endpoints directly with:

curl -v https://

can help confirm whether the proxy path is actually used.

[wchengjia]

This is useful, thanks for help.