Личный VPN-заменитель через SSH

2026-06-16 12:00 Kirill Arkhipenko ssh, proxy, networking, linux, cloud, security

Коммерческие VPN-сервисы всё чаще ведут себя как зонтики из рисовой бумаги: вроде есть, вроде красивые, но первый крепкий дождь из DPI, списков запрещённых адресов и заблокированных протоколов превращает их в мокрую грусть.

При этом у любого человека, который хоть немного дружит с командной строкой, под рукой есть старый, крепкий и удивительно живучий способ: SSH-туннель с SOCKS5-прокси.

Идея проста: вы берёте маленькую облачную машину, подключаетесь к ней по SSH и просите SSH-клиент открыть у вас на компьютере локальный порт. Всё, что вы направите в этот порт, уходит по зашифрованному каналу на ваш сервер и выходит в сеть уже с его адреса.

Не надо поднимать OpenVPN. Не надо собирать WireGuard. Не надо покупать очередной «самый надёжный VPN», который завтра может перестать дышать.

Нужен только сервер, ключ SSH и одна команда.

Материал актуален на 16 июня 2026 года. Условия облаков меняются, поэтому перед созданием машины обязательно проверяйте нынешние тарифы и ограничения в личном кабинете.

Что мы строим

Мы поднимем личный SOCKS5-прокси на базе SSH.

На вашем устройстве будет открыт локальный адрес:

127.0.0.1:1080

Браузер, отдельные приложения или весь телефонный сетевой поток можно будет направить туда. Дальше всё пойдёт через зашифрованное SSH-соединение на вашу облачную машину.

Снаружи это выглядит так:

Ваш браузер -> 127.0.0.1:1080 -> SSH-туннель -> облачная ВМ -> нужный сайт

Для внешнего мира вы выходите в сеть с адреса облачного сервера.

Для наблюдателя между вами и сервером это выглядит как обычное SSH-подключение к удалённой машине. Такое соединение каждый день используют разработчики, администраторы, сборочные системы, хранилища кода и куча рабочих служб.

Когда такой способ хорош

SSH-туннель особенно хорош в двух случаях.

Первый случай: нужен зарубежный выход в сеть. Например, вы хотите открывать зарубежные службы, хранилища кода, справочные сайты, ИИ-помощники, СМИ или личные учётные записи, которые плохо работают из вашей текущей сети.

Второй случай: нужен российский выход в сеть из-за границы. Например, вы уехали, а банк, Госуслуги, местный видеосервис или иной российский сайт не любит зарубежные IP-адреса.

В обоих случаях вам нужен не «VPN вообще», а свой маленький сетевой выход в нужной стране.

Когда SSH-туннель не заменяет полноценный VPN

Важно не превращать этот способ в волшебную палочку из алюминиевой фольги.

SOCKS5 через SSH отлично подходит для браузера, curl, git, мессенджеров с ручной настройкой прокси и многих обычных задач.

Но есть ограничения:

Не все приложения умеют ходить через SOCKS5.
Часть программ может делать DNS-запросы мимо прокси.
UDP обычно не проходит через такой туннель.
Игры, звонки, некоторые видеослужбы и приложения с хитрой сетевой логикой могут работать плохо.
Если сервер далеко, задержка будет выше.
Если вы качаете большие объёмы данных, бесплатный облачный предел быстро закончится.

Проще говоря: для чтения, работы, почты, кода, справочников и личного доступа это прекрасный карманный ход. Для торрентов, игр, видеозвонков и «завернуть всю жизнь через один порт» лучше поднимать полноценный VPN или пользоваться особыми средствами на уровне системы.

Что понадобится

Минимальный набор:

Облачная виртуальная машина.
Публичный IP-адрес этой машины.
SSH-ключ.
SSH-клиент на вашем устройстве.
Браузерное расширение или системная настройка прокси.

На Linux и macOS SSH уже обычно есть. На Windows 10 и Windows 11 OpenSSH тоже встроен. Проверить можно так:

ssh -V

Если команда отвечает версией, всё готово.

Выбор облака

Нам нужна маленькая ВМ с публичным адресом.

Лучше всего держать две машины:

proxy-us: сервер в США или Европе для доступа к зарубежным службам.
proxy-ru: сервер в России для доступа к российским службам из-за границы.

Можно начать с одной.

Вариант 1: Google Cloud для зарубежного выхода

У Google Cloud есть бесплатный предел для Compute Engine: одна маленькая машина e2-micro в некоторых регионах США, стандартный постоянный диск до 30 ГБ и небольшой бесплатный исходящий сетевой объём.

Для личного прокси это удобно, но есть тонкости:

Тип машины: e2-micro
Регионы: us-west1, us-central1 или us-east1
Диск: standard persistent disk, до 30 ГБ
Система: Debian или Ubuntu
Сетевой объём: следите за исходящим трафиком

Хороший выбор для старта:

Регион: us-central1
Зона: us-central1-a
Система: Debian 12
Тип: e2-micro
Диск: 30 GB, standard persistent disk

Google может показывать примерную месячную стоимость машины в панели. Это не всегда значит, что деньги спишутся: в пределах бесплатных условий стоимость перекрывается бесплатным уровнем. Но превышение пределов, например по исходящему сетевому потоку, уже может стоить денег.

Поэтому сразу включите бюджетное оповещение в платёжном разделе. Это скучный шаг, зато он спасает от счёта, который появляется как леший из тумана.

Вариант 2: Cloud.ru для российского выхода

Cloud.ru интересен тем, что у него есть бесплатная виртуальная машина на платформе Evolution:

vCPU
ГБ RAM
ГБ SSD NVMe

Для личного прокси это даже жирновато. Но есть важная оговорка на 2026 год: в документации Cloud.ru указано, что создание новой бесплатной ВМ недоступно пользователям, которые раньше такую ВМ никогда не создавали. Поэтому этот путь сейчас стоит рассматривать так:

Если бесплатная ВМ уже доступна в вашем личном кабинете, это отличный вариант.
Если вы новый пользователь, проверьте доступность в панели до того, как строить весь план вокруг Cloud.ru.

Даже когда сама ВМ бесплатна, внешний публичный IP-адрес обычно оплачивается отдельно. В примерах Cloud.ru встречается порядок около 146 рублей в месяц за один публичный IP, но точную цену нужно смотреть в тарифах на день создания.

Плюс: входящий и исходящий сетевой поток для ВМ у Cloud.ru временно не тарифицируется, но это тоже надо перепроверять перед запуском. Слово «временно» в тарифах всегда надо читать с поднятой бровью.

А Oracle, AWS и прочие?

Oracle Cloud часто всплывает в разговорах о бесплатных машинах. Но условия бесплатных пределов у больших облаков меняются, иногда довольно резко. Для статьи-памятки лучше держать простой принцип:

Не выбирайте облако по старой статье.
Откройте нынешнюю страницу Free Tier.
Проверьте регион, тип машины, диск, публичный IP и исходящий сетевой поток.
Сразу включите ограничение расходов.

Для личного SSH-прокси нам не нужна мощность. Нам нужна предсказуемость.

Создаём SSH-ключ

На своём компьютере создайте отдельный ключ только для прокси:

ssh-keygen -t ed25519 -C "personal-ssh-proxy" -f ~/.ssh/proxy_ed25519

Права на ключ:

chmod 600 ~/.ssh/proxy_ed25519

Публичный ключ лежит здесь:

cat ~/.ssh/proxy_ed25519.pub

Его нужно добавить в облачную машину.

Важная тонкость Google Cloud: имя пользователя в SSH-ключе

Если вы добавляете ключ в Google Cloud вручную через метаданные, внимательно смотрите на формат.

В обычном виде публичный ключ выглядит так:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... personal-ssh-proxy

Для Google Cloud в разных местах используются разные записи:

USERNAME:ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... personal-ssh-proxy

или:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... USERNAME

Смысл один: Google должен понять, под каким пользователем создать доступ.

Например, вы хотите заходить как proxy:

proxy:ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... personal-ssh-proxy

Не полагайтесь на браузерную кнопку SSH в панели Google, если хотите потом спокойно входить из локального терминала. Браузерный вход может создать пользователя на основе вашей почты, и потом вы будете гадать, почему ssh proxy@IP не пускает, хотя «в панели всё работало».

Лучше сразу явно задать имя пользователя и ключ.

Первый вход на сервер

После создания машины у вас будет внешний IP-адрес. Проверяем вход:

ssh -i ~/.ssh/proxy_ed25519 proxy@IP_ВАШЕГО_СЕРВЕРА

Пример:

ssh -i ~/.ssh/proxy_ed25519 proxy@203.0.113.10

Если сервер впервые виден вашему компьютеру, SSH спросит, доверять ли отпечатку ключа. Сверьте его с тем, что показывает облако, если такая возможность есть. Затем согласитесь.

Минимальная команда для прокси

Вот сердцевина всей схемы:

ssh -i ~/.ssh/proxy_ed25519 -N -D 127.0.0.1:1080 proxy@IP_ВАШЕГО_СЕРВЕРА

Разбор:

-i ~/.ssh/proxy_ed25519: использовать выбранный ключ.
-N: не запускать удалённую команду, только держать соединение.
-D 127.0.0.1:1080: открыть локальный SOCKS-прокси на порту 1080.
proxy@IP: пользователь и адрес сервера.

Пока команда работает, у вас открыт локальный SOCKS5-прокси:

127.0.0.1:1080

Оставьте окно терминала открытым и переходите к настройке браузера.

Проверяем, что туннель живой

Проверка через curl:

curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

Команда должна показать IP вашего облачного сервера.

Почему именно --socks5-hostname, а не просто --socks5? Потому что так имя сайта разрешается через прокси, а не на вашей стороне. Это снижает риск DNS-утечек.

Можно также проверить обычный выход:

curl https://ifconfig.me

Если два адреса разные, всё работает.

Настраиваем Firefox

Firefox удобен тем, что умеет аккуратно работать с SOCKS5 и удалённым DNS.

Откройте:

Settings -> Network Settings -> Manual proxy configuration

Дальше:

SOCKS Host: 127.0.0.1
Port: 1080
SOCKS v5: включить
Proxy DNS when using SOCKS v5: включить

Последний флажок очень важен. Без него браузер может спрашивать IP-адреса сайтов у вашего обычного DNS-сервера, даже если сам сайт открывает через прокси.

Для удобства можно сделать отдельный профиль Firefox только под прокси:

firefox -P

Назовите его, например:

proxy-us

Так у вас будет отдельный «сетевой плащ»: один браузер ходит напрямую, второй через туннель.

Настраиваем Chrome, Edge и другие Chromium-браузеры

У Chromium-браузеров всё менее прозрачно: они часто берут системные настройки прокси, а расширения и отдельные составные части могут вести себя по-разному.

Самый удобный путь: расширение FoxyProxy, SmartProxy или ZeroOmega.

Создайте правило:

Type: SOCKS5
Host: 127.0.0.1
Port: 1080

Дальше можно сделать списки:

*.openai.com -> через proxy-us
*.google.com -> через proxy-us
*.gosuslugi.ru -> через proxy-ru
рабочие сайты -> напрямую

Для временного запуска Chrome только через прокси можно использовать:

google-chrome --proxy-server="socks5://127.0.0.1:1080"

На macOS:

open -a "Google Chrome" --args --proxy-server="socks5://127.0.0.1:1080"

Но для постоянной жизни удобнее расширение с правилами.

Настраиваем командную строку

Многие средства умеют ходить через SOCKS5.

curl

curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

git

Разовый запуск:

git -c http.proxy=socks5h://127.0.0.1:1080 clone https://github.com/example/project.git

Постоянная настройка:

git config --global http.proxy socks5h://127.0.0.1:1080
git config --global https.proxy socks5h://127.0.0.1:1080

Снять настройку:

git config --global --unset http.proxy
git config --global --unset https.proxy

Обратите внимание на socks5h. Буква h означает, что имя узла будет разрешаться через прокси.

Переменные окружения

Некоторые программы читают такие переменные:

export ALL_PROXY=socks5h://127.0.0.1:1080
export HTTP_PROXY=socks5h://127.0.0.1:1080
export HTTPS_PROXY=socks5h://127.0.0.1:1080

Снять:

unset ALL_PROXY HTTP_PROXY HTTPS_PROXY

Делаем удобный SSH-настрой

Чтобы не писать длинную команду каждый раз, добавьте сервер в ~/.ssh/config:

Host proxy-us
  HostName 203.0.113.10
  User proxy
  IdentityFile ~/.ssh/proxy_ed25519
  IdentitiesOnly yes
  DynamicForward 127.0.0.1:1080
  ServerAliveInterval 30
  ServerAliveCountMax 3
  ExitOnForwardFailure yes
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist yes

Теперь запуск выглядит так:

ssh -N proxy-us

Запуск в фоне:

ssh -f -N proxy-us

Остановить соединение:

ssh -O exit proxy-us

Если у вас две машины, например США и Россия, разведите порты:

Host proxy-us
  HostName IP_СЕРВЕРА_В_США
  User proxy
  IdentityFile ~/.ssh/proxy_ed25519
  IdentitiesOnly yes
  DynamicForward 127.0.0.1:1080
  ServerAliveInterval 30
  ServerAliveCountMax 3
  ExitOnForwardFailure yes
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist yes

Host proxy-ru
  HostName IP_СЕРВЕРА_В_РОССИИ
  User proxy
  IdentityFile ~/.ssh/proxy_ed25519
  IdentitiesOnly yes
  DynamicForward 127.0.0.1:1081
  ServerAliveInterval 30
  ServerAliveCountMax 3
  ExitOnForwardFailure yes
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist yes

Тогда:

127.0.0.1:1080 -> США
127.0.0.1:1081 -> Россия

В расширении браузера можно сделать правила по доменам.

Автозапуск на Linux через systemd

Если вы хотите, чтобы туннель поднимался сам после входа в систему, создайте пользовательскую службу.

Файл:

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/ssh-proxy-us.service

Содержимое:

[Unit]
Description=SSH SOCKS tunnel to proxy-us
After=network-online.target

[Service]
ExecStart=/usr/bin/ssh -N proxy-us
Restart=always
RestartSec=5

[Install]
WantedBy=default.target

Включаем:

systemctl --user daemon-reload
systemctl --user enable --now ssh-proxy-us.service

Проверяем:

systemctl --user status ssh-proxy-us.service

Чтобы служба работала даже без открытого рабочего сеанса:

loginctl enable-linger "$USER"

Остановить:

systemctl --user stop ssh-proxy-us.service

Отключить автозапуск:

systemctl --user disable ssh-proxy-us.service

Автозапуск на macOS

Самый простой способ: держать ~/.ssh/config и запускать туннель одной командой после входа:

ssh -f -N proxy-us

Для более строгого автозапуска можно создать launchd-службу, но для личного прокси чаще хватает ярлыка или маленького shell-скрипта:

#!/usr/bin/env bash
ssh -f -N proxy-us

Сохраните как:

~/bin/start-proxy-us

Права:

chmod +x ~/bin/start-proxy-us

Автозапуск на Windows

На Windows можно использовать встроенный OpenSSH и Планировщик заданий.

Проверьте путь к SSH:

where ssh

Обычно это:

C:\Windows\System32\OpenSSH\ssh.exe

Команда запуска:

ssh -f -N proxy-us

Если -f ведёт себя неудобно, создайте задачу, которая запускает:

ssh -N proxy-us

и держит окно скрытым через PowerShell-обёртку или Windows Terminal-профиль.

Более простой путь: установить удобный SSH-клиент с поддержкой туннелей и автозапуска, но встроенного OpenSSH вполне достаточно.

Укрепляем сервер

Не оставляйте сервер «как создался». Минимальная гигиена нужна даже для маленькой машины.

1. Обновите систему

Debian или Ubuntu:

sudo apt update
sudo apt upgrade -y

2. Запретите вход по паролю

Откройте отдельный SSH-сеанс и не закрывайте текущий, пока не проверите новые настройки.

Создайте файл:

sudo nano /etc/ssh/sshd_config.d/99-proxy-hardening.conf

Содержимое:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowTcpForwarding local
X11Forwarding no
AllowAgentForwarding no

Проверка:

sudo sshd -t

Перезагрузка SSH-службы:

sudo systemctl reload ssh

На некоторых системах служба называется sshd:

sudo systemctl reload sshd

После этого откройте новый терминал и проверьте вход по ключу:

ssh proxy-us

Только когда новый вход работает, закрывайте старый сеанс.

3. Ограничьте вход по сети

Если у вас постоянный домашний IP, можно открыть SSH только с него. На Ubuntu удобно использовать UFW:

sudo ufw allow from ВАШ_IP to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Если домашний IP меняется, этот шаг может сам вас запереть снаружи. В таком случае хотя бы оставьте вход только по ключу.

4. Не открывайте SOCKS-порт наружу

Ключевой момент:

Правильно: 127.0.0.1:1080
Опасно: 0.0.0.0:1080

Когда вы пишете:

-D 127.0.0.1:1080

прокси слушает только ваш собственный компьютер.

Когда вы пишете:

-D 0.0.0.0:1080

вы рискуете открыть прокси для всей сети. Так делать не надо, если вы точно не понимаете, зачем это нужно и как закрыть доступ межсетевыми правилами.

Как не протекать DNS-запросами

DNS-утечка: это когда сам сайт открывается через прокси, но запрос «какой IP у example.com?» уходит через обычного поставщика сети.

Чтобы снизить риск:

В Firefox включите Proxy DNS when using SOCKS v5.
В curl используйте --socks5-hostname.
В git и переменных окружения используйте socks5h://, а не socks5://.
В браузерных расширениях выбирайте SOCKS5 и проверяйте настройки DNS.

Проверка:

Запустите туннель.
Откройте сайт проверки IP.
Откройте сайт проверки DNS-утечек.
Убедитесь, что видны DNS-серверы страны вашего прокси или хотя бы не видны ваши обычные местные DNS.

Полной тайности этот способ не обещает. Наша цель другая: личный управляемый туннель без чужого VPN-поставщика посередине.

Телефон: Android

На Android схема наиболее приятная: SSH-клиент держит туннель, а отдельное приложение направляет сетевой поток в локальный SOCKS5.

Вариант A: Termux плюс SocksDroid

Установите Termux. Лучше брать свежую сборку из F-Droid, потому что старые сборки из магазинов приложений могут быть давно не обновлены.

В Termux:

pkg update
pkg install openssh

Скопируйте приватный ключ на телефон или создайте новый ключ прямо на телефоне:

ssh-keygen -t ed25519 -C "android-proxy" -f ~/.ssh/proxy_ed25519
chmod 600 ~/.ssh/proxy_ed25519

Публичный ключ добавьте на сервер.

Запуск туннеля:

ssh -i ~/.ssh/proxy_ed25519 -N -D 127.0.0.1:1080 proxy@IP_СЕРВЕРА

Теперь нужен перехват сетевого потока. Для этого подходит SocksDroid.

Настройка SocksDroid:

Server Address: 127.0.0.1
Server Port: 1080
Proxy Type: SOCKS5

Включите главный переключатель.

SocksDroid создаёт локальное VPN-соединение средствами Android. Система думает, что отдаёт сетевой поток в VPN, а приложение перенаправляет его в ваш локальный SOCKS5-порт.

Что важно:

Отключите строгую экономию батареи для Termux и SocksDroid.
Не закрывайте уведомление Termux.
Проверьте, что туннель жив после блокировки экрана.

Вариант B: Termius плюс SocksDroid

Если вам не хочется жить в командной строке, используйте SSH-клиент с графической настройкой туннелей.

В Termius:

Host -> Port Forwarding -> Add rule
Type: Dynamic / SOCKS5
Local host: 127.0.0.1
Local port: 1080

Подключитесь к серверу. Затем в SocksDroid укажите:

127.0.0.1:1080

Этот вариант удобнее для тех, кто часто переключается между proxy-us и proxy-ru.

Телефон: iPhone и iPad

На iOS всё строже. Система не любит долгие фоновые SSH-сеансы и может прибивать их после простоя. Поэтому здесь нет такого же простого «поставил и забыл», как на Android.

Лучший путь: Blink Shell

Blink Shell умеет поднимать SOCKS5 через SSH и даёт готовый PAC-файл для системной настройки Wi-Fi-прокси.

Запуск туннеля в Blink:

ssh -D 10800 proxy@IP_СЕРВЕРА

Почему порт 10800, а не 1080? На iOS порт 1080 часто занят системой, а Blink использует 10800 в своём готовом файле настройки.

Дальше на iPhone:

Settings -> Wi-Fi -> ваша сеть -> кнопка (i)
HTTP Proxy -> Configure Proxy -> Automatic
URL: https://blink.sh/proxy.pac

После этого HTTP и HTTPS-соединения по Wi-Fi пойдут через локальный порт Blink.

Чтобы iOS не убивала сеанс слишком быстро, в Blink есть обходной приём с отслеживанием местоположения:

geo track

Это не полноценный VPN на всё устройство. Это системный Wi-Fi-прокси для HTTP/HTTPS и TCP-потока, который дружит с такой схемой. Для многих сайтов и приложений этого достаточно, но не для всего.

Другие iOS-приложения

В App Store есть SSH-клиенты с туннелями, например WebSSH и похожие приложения. Ищите поддержку:

Dynamic port forwarding
SOCKS5 tunnel
Local SOCKS proxy
PAC file

Некоторые приложения дают встроенный браузер: вы открываете сайты прямо внутри SSH-клиента. Это менее удобно, зато часто устойчивее, потому что iOS меньше спорит с таким способом.

Два прокси сразу: США и Россия

Самый удобный итоговый строй:

proxy-us -> 127.0.0.1:1080
proxy-ru -> 127.0.0.1:1081

В браузерном расширении:

Зарубежные ИИ-службы -> proxy-us
Зарубежные хранилища кода -> proxy-us
Российские банки -> proxy-ru
Госуслуги -> proxy-ru
Остальное -> напрямую

Так вы не гоняете весь сетевой поток через один узкий проход. Каждый сайт идёт туда, куда нужно.

Частые поломки и быстрые ответы

Ошибка: Permission denied (publickey)

Причины:

Неверный пользователь.
Не тот ключ.
Ключ не добавлен в метаданные облака.
На сервере неправильные права на ~/.ssh.
В Google Cloud включён OS Login, а вы добавляете ключи в метаданные.

Проверка:

ssh -vvv proxy-us

Ищите строки, где SSH пишет, какие ключи он пробует.

Ошибка: bind: Address already in use

Порт уже занят. Проверьте:

ss -ltnp | grep 1080

На macOS:

lsof -iTCP:1080 -sTCP:LISTEN

Решение: остановите старый туннель или используйте другой порт, например 1081.

Браузер не открывает сайты

Проверьте по порядку:

Жив ли SSH-сеанс?
Слушает ли порт 1080?
Правильно ли указан SOCKS5, а не HTTP-прокси?
Включён ли удалённый DNS?
Не стоит ли в расширении правило DIRECT выше правила прокси?

Сайт всё равно видит мой обычный IP

Значит конкретное приложение не использует прокси.

Проверьте через curl:

curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

Если curl показывает IP сервера, туннель исправен. Проблема в настройке приложения.

Работает медленно

Возможные причины:

Сервер далеко.
У маленькой ВМ слабая доля процессорного времени.
Сайт тяжёлый.
Вы гоните видео через бесплатный предел.
Маршрут от вашего поставщика сети до облака плохой.

Иногда помогает сжатие:

ssh -C -N -D 127.0.0.1:1080 proxy@IP_СЕРВЕРА

Но для уже сжатого видео, картинок и архивов толку почти не будет.

Работают сайты, но не звонки и игры

Скорее всего, приложение использует UDP или свою сетевую схему. Обычный SSH SOCKS5 для этого не подходит. Нужен полноценный VPN или иная системная сетенастройка.

Сколько это стоит на самом деле

Честная таблица:

Google Cloud e2-micro: может быть 0 рублей в месяц в пределах Always Free.
Google Cloud исходящий поток: малый бесплатный предел, дальше возможна оплата.
Cloud.ru free VM: отлично, если доступна в вашем кабинете.
Cloud.ru публичный IP: обычно оплачивается отдельно.
Cloud.ru сетевой поток: временно не тарифицируется, проверяйте перед запуском.

Главное правило:

Перед созданием машины включите бюджетные оповещения.
Не используйте прокси для больших загрузок.
Не держите лишние диски, снимки и платные IP без нужды.
Раз в месяц смотрите счёт.

Бесплатное облако бесплатно только для внимательных.

Безопасность и разумные границы

Собственный прокси не делает вас невидимкой.

Облачный поставщик видит, что ваша машина ходит к внешним адресам. Сайты видят IP вашего сервера. SSH защищает путь от вашего устройства до сервера, но дальше соединение идёт обычным образом. Поэтому:

Используйте HTTPS.
Не вводите пароли на подозрительных сайтах.
Не открывайте прокси наружу.
Не давайте ключи другим людям.
Не используйте сервер для спама, взлома, брутфорса и торрент-помоек.
Проверяйте правила своей сети и законы страны, где вы находитесь.

Этот способ нужен для личного доступа, работы, чтения и нормальной сетевой жизни. Не для серых дел.

Быстрый рецепт для нетерпеливых

Создайте маленькую ВМ в нужной стране.
Добавьте SSH-ключ.

Проверьте вход:

ssh -i ~/.ssh/proxy_ed25519 proxy@IP_СЕРВЕРА

Запустите туннель:

ssh -i ~/.ssh/proxy_ed25519 -N -D 127.0.0.1:1080 proxy@IP_СЕРВЕРА

Проверьте IP:

curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

В Firefox укажите:

SOCKS Host: 127.0.0.1
Port: 1080
SOCKS v5
Proxy DNS when using SOCKS v5

Для постоянного запуска добавьте ~/.ssh/config:

Host proxy-us
  HostName IP_СЕРВЕРА
  User proxy
  IdentityFile ~/.ssh/proxy_ed25519
  IdentitiesOnly yes
  DynamicForward 127.0.0.1:1080
  ServerAliveInterval 30
  ServerAliveCountMax 3
  ExitOnForwardFailure yes

Запускайте одной командой:
```
ssh -f -N proxy-us
```

Готово. У вас свой личный сетевой ход, без чужого VPN-приложения, без мутных подписок и без ощущения, что ваш трафик ночует в чьём-то подвале.

Итог

SSH-туннель с SOCKS5-прокси хорош тем, что он прост, прозрачен и управляем.

Вы сами выбираете страну выхода. Вы сами держите ключи. Вы сами видите сервер. Вы сами решаете, какие сайты идут через туннель, а какие напрямую.

Это не замена всем VPN на свете. Но как личный рабочий «телепорт» для браузера, кода, справочников, банковских кабинетов и повседневного доступа это один из самых живучих способов в 2026 году.

Маленькая ВМ в облаке, один SSH-ключ, один локальный порт, и у вас в кармане появляется собственная дверца в нужную часть сети.

Что мы строим

Когда такой способ хорош

Когда SSH-туннель не заменяет полноценный VPN

Что понадобится

Выбор облака

Вариант 1: Google Cloud для зарубежного выхода

Вариант 2: Cloud.ru для российского выхода

А Oracle, AWS и прочие?

Создаём SSH-ключ

Важная тонкость Google Cloud: имя пользователя в SSH-ключе

Первый вход на сервер

Минимальная команда для прокси

Проверяем, что туннель живой

Настраиваем Firefox

Настраиваем Chrome, Edge и другие Chromium-браузеры

Настраиваем командную строку

curl

git

Переменные окружения

Делаем удобный SSH-настрой

Автозапуск на Linux через systemd

Автозапуск на macOS

Автозапуск на Windows

Укрепляем сервер

1. Обновите систему

2. Запретите вход по паролю

3. Ограничьте вход по сети

4. Не открывайте SOCKS-порт наружу

Как не протекать DNS-запросами

Телефон: Android

Вариант A: Termux плюс SocksDroid

Вариант B: Termius плюс SocksDroid

Телефон: iPhone и iPad

Лучший путь: Blink Shell

Другие iOS-приложения

Два прокси сразу: США и Россия

Частые поломки и быстрые ответы

Ошибка: Permission denied (publickey)

Ошибка: bind: Address already in use

Браузер не открывает сайты

Сайт всё равно видит мой обычный IP

Работает медленно

Работают сайты, но не звонки и игры

Сколько это стоит на самом деле

Безопасность и разумные границы

Быстрый рецепт для нетерпеливых

Итог

Loading tracks