- Security
- A
Here's the translated text you requested: How I made friends with Yandex Cloud and Gemini API without migrating to foreign servers
When I started writing the Node.js service that was supposed to integrate with the LLM model, I already understood that access to some foreign APIs from Russia could be problematic. That's why my initial choice was Yandex Cloud's model — Yandex GPT.
But after my colleagues and I had a brief chat with it, it became clear that Yandex GPT wasn't suitable for us. Its responses were too unnatural, "non-human" — especially noticeable in our specific case. So we had to look for alternatives among foreign models. The option of training our own model was immediately ruled out — I had no experience with it, and there was no time to find someone who could do it, as we wanted to launch quickly. So, the choice fell on Gemini API from Google, which had received many positive reviews.
However, this meant we had to solve the problem of access from Russia, as my service was hosted on Yandex Cloud.
Move everything to foreign servers? I really didn’t want to...
It was clear right away that Gemini wouldn’t provide access to my service from Russia, and I started to get frustrated. I already had a working infrastructure in Yandex Cloud, and there was very little time left until the release. The realization that I would have to move the service or at least deploy an additional server somewhere, set up the environment, configure the deployment, and deal with a new infrastructure didn’t add optimism.
Moreover, I fully understood that any migration isn’t just moving code. It also involves:
potential errors during deployment,
the need to rebuild CI/CD,
additional monitoring of the new server.
The more I thought about it, the less appealing it seemed. And the main thing was — there simply wasn’t enough time for all of this, because the deadlines were already tight.
And then, just when I was almost starting to accept the inevitability of migration, a completely different thought crossed my mind: why even move the infrastructure? After all, the problem was just with access to the API, and it could be solved in another way — for example, through a VPN proxy directly from the Node.js service.
Node.js + VPN — could this work?
It’s unlikely that I’m the first one to encounter such a problem, so I almost immediately started looking for a suitable solution in the direction of VPN or proxy. And it turned out to be much easier than I expected.
My application is written in Node.js, and initially, I used the standard built-in fetch
, which appeared in the latest versions of Node.js and eliminates the need to install external packages. I asked myself: can I make this standard fetch
send requests through a VPN proxy?
It didn’t allow that, but I found an external package node-fetch
, which is guaranteed to work with the socks-proxy-agent
package.
Minimal working example:
import fetch from 'node-fetch';
import { SocksProxyAgent } from 'socks-proxy-agent';
const proxy = 'socks5h://логин:пароль@адрес_вашего_прокси:порт';
const agent = new SocksProxyAgent(proxy);
const response = await fetch('https://generativelanguage.googleapis.com/v1beta/models/...', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ /* ваши данные */ }),
agent,
});
const data = await response.json();
console.log(data);
It worked immediately and without any additional configuration.
How I quickly set up my VPN proxy
I didn't want to waste time on complicated configurations and found a simple solution — Amnezia VPN. It’s a free and open-source tool that allows you to set up your own VPN server in just a few commands (for example, on a virtual machine in Hetzner or DigitalOcean).
In half an hour, I did the following:
I took a minimal VPS from an overseas hosting provider.
I set up the Amnezia server with a single command.
I got a ready-to-use SOCKS5 proxy with an IP address in an "allowed" region.
Gemini started responding as soon as I plugged this proxy into my code.
So instead of a complete infrastructure migration, I got a fully working solution in just half an hour.
But what if the VPN suddenly goes down?
The solution was simple and elegant, but the following question arose: what if the VPN server goes down? Or if the proxy gets blocked by Google or Yandex?
After all, relying on a single VPN proxy makes the whole system unreliable.
I quickly realized I needed to add support for multiple proxies with automatic switching between them in case of failures.
And that's exactly what I did.
Support for multiple proxies and automatic switching
To avoid dependency on a single proxy and improve fault tolerance, I decided to implement a simple failover mechanism. The idea is simple:
The service takes a list of proxies.
If the main proxy is unavailable (returns an error or times out), the service automatically tries the next one in the list.
And so on until a working proxy is found or the list runs out.
This allowed me not to worry about the VPN server suddenly going down or getting banned.
NPM package for anyone who needs it: fetch-retry-proxy
When I finished implementing this mechanism, I thought that surely I wasn’t the only one facing this task. So that other developers could quickly solve a similar problem, I moved all this functionality to a separate npm module:
📦 fetch-retry-proxy
🐙 GitHub repository with source code and tests
Now anyone can install it with a single command:
npm install fetch-retry-proxy
And use it like this:
import fetchRetryProxy from 'fetch-retry-proxy';
const proxies = [
'socks5h://proxy1:port',
'socks5h://proxy2:port',
'socks5h://proxy3:port',
];
const response = await fetchRetryProxy('https://generativelanguage.googleapis.com/...', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ /* data */ }),
}, proxies);
const data = await response.json();
console.log(data);
Thus, in just a few minutes, you can get a reliable solution with automatic switching between multiple proxy servers.
I also uploaded the source code and tests to GitHub so it's easy to understand how it works or suggest improvements.
Result: It turned out to be easier than I thought
In the end, instead of migrating the entire infrastructure to another country, I got a simple and convenient solution:
The service continues to run in Yandex Cloud.
Access to the Gemini API is stable and protected from disruptions.
Other developers can use the ready-made npm package and save time.
I hope my experience helps you save your nerves and time. Have you encountered similar situations? Share in the comments!
Write comment