Hello,
I would like to share a networking issue I encountered with the Gemini Live API using the Google Gen AI Python SDK.
In my environment, Gemini Live WebSocket connections were intermittently failing during the opening handshake. I eventually found that the problem was related to the IPv6 network path to generativelanguage.googleapis.com.
This may be useful for others experiencing similar “timed out during opening handshake” errors.
Environment
- Raspberry Pi 5 (8 GB)
- Debian GNU/Linux 13 (trixie)
- Python 3.13.5
- google-genai 2.22.0
- websockets 16.1.1
- Model: gemini-3.1-flash-live-preview
- Gemini Developer API
- Live API using AUDIO response modality
- Wi-Fi network with IPv6 enabled
Symptom
The application sometimes failed to establish a Gemini Live session with:
timed out during opening handshake
The log looked like:
[GEMINI LIVE DIAG] CONNECT | model='gemini-3.1-flash-live-preview'
...
timed out during opening handshake
The timeout occurred during the WebSocket connection itself, before normal Live API communication could begin.
Interestingly, the same application, API key, model, and Raspberry Pi could connect successfully at other times.
I also tested another Live model, gemini-3.8-live, but experienced the same handshake timeout. Therefore, changing the model did not appear to be the solution.
Network investigation
DNS resolution itself appeared to be normal.
For example:
getent ahosts generativelanguage.googleapis.com
returned both IPv6 and IPv4 addresses.
However, IPv6 connectivity to Google’s endpoint was not working correctly.
An IPv4 HTTPS test succeeded:
curl -4 -I https://generativelanguage.googleapis.com
This successfully established a TCP/TLS/HTTP connection and returned an HTTP response from Google.
In contrast:
curl -6 -I https://generativelanguage.googleapis.com
hung until timeout.
I also tested direct TCP connections to multiple IPv6 addresses returned for generativelanguage.googleapis.com. All of them timed out.
IPv6 ping also showed 100% packet loss.
Therefore, the situation appeared to be:
DNS resolution -> OK
IPv4 TCP/443 -> OK
IPv4 TLS/HTTPS -> OK
IPv6 TCP/443 -> TIMEOUT
Gemini Live over IPv6 -> opening handshake timeout
Workaround
The Google Gen AI SDK ultimately uses the hostname:
generativelanguage.googleapis.com
for the Live WebSocket connection.
Instead of disabling IPv6 system-wide, I applied a process-local workaround that forces IPv4 only for this specific hostname.
I added the following before creating the Gemini client:
import socket
_GEMINI_IPV4_HOST = "generativelanguage.googleapis.com"
_ORIGINAL_GETADDRINFO = socket.getaddrinfo
def _gemini_ipv4_getaddrinfo(
host,
port,
family=0,
type=0,
proto=0,
flags=0,
):
if (
isinstance(host, str)
and host.rstrip(".").lower() == _GEMINI_IPV4_HOST
and family in (0, socket.AF_UNSPEC)
):
family = socket.AF_INET
return _ORIGINAL_GETADDRINFO(
host,
port,
family,
type,
proto,
flags,
)
socket.getaddrinfo = _gemini_ipv4_getaddrinfo
This only changes address-family selection for:
generativelanguage.googleapis.com
Other hostnames are not affected.
It also does not override an explicit AF_INET6 request.
Test results
I created a small test program using the actual google-genai client and applied the same getaddrinfo override.
I ran 10 consecutive Gemini Live connection tests.
Results:
10 / 10 successful
WebSocket handshake times were approximately:
0.49 - 0.66 seconds
Each session was then kept alive for 10 seconds without disconnecting.
Before forcing IPv4, the same type of connection repeatedly failed with:
timed out during opening handshake
Production test
I then applied the workaround to my actual AI robot application.
After restarting the service, the application successfully established Gemini Live connections and completed normal conversations.
For example, the robot successfully:
- established a Gemini Live session
- received Gemini audio responses
- performed function calls
- processed user speech
- generated normal responses
- used VOICEVOX for speech output
No “timed out during opening handshake” error occurred during the production test.
Important observation
I am not claiming that this is a Gemini Live API bug.
The evidence from my environment suggests that the IPv6 path between my network and Google’s generativelanguage.googleapis.com endpoint was not usable, while IPv4 was working correctly.
The important point is that the Gemini Live SDK appeared to be able to select an IPv6 address, and the broken IPv6 route caused the WebSocket opening handshake to time out.
For environments with broken or partially working IPv6 connectivity, automatically preferring IPv4 for this endpoint may be a useful workaround.
Question
Could the Gemini API / python-genai team confirm whether there is a recommended way to configure the SDK or WebSocket transport to prefer IPv4 for Gemini Live connections?
If there is already a supported configuration for controlling address-family selection, I would prefer to use that instead of monkeypatching socket.getaddrinfo.
I am sharing this because the symptom initially looked like a Gemini Live service or model problem, but network-level testing showed a very different cause.
Thank you.