Linux && Windows


Установка веб-серверов Nginx и Apache.

Итоговая архитектура для разработки предполагается такая:

                Internet
                    ↓
        ┌─────────────────────┐
        │       Nginx         │  ← порт 8081 (вход)
        └─────────────────────┘
            ↓            ↓
     WordPress      .NET apps (опционально)
     (Apache)           (Kestrel)
            ↓
        MariaDB
        PostgreSQL

🥇 Роли компонентов

🌐 Nginx (front door)

🟦 Apache (только WordPress)

Apache HTTP Server

🚀 ШАГ 1 — установка пакетов

В Ubuntu:

sudo apt update

sudo apt install -y nginx

sudo apt install -y apache2

sudo apt install -y mariadb-server
sudo apt install -y postgresql

⚙️ ШАГ 2 — порты (ВАЖНО)

Apache уводим с 80:

sudo nano /etc/apache2/ports.conf

Примерное содержимое:

Listen 8082

<IfModule ssl_module>
	Listen 443
</IfModule>

<IfModule mod_gnutls.c>
	Listen 443
</IfModule>

И в site config:

sudo nano /etc/apache2/sites-available/000-default.conf

Примерное содержимое с учетом проекта на wordpress:

<VirtualHost *:8082>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html

	Alias /portfolio /mnt/d/Soft/Freelance/Wordpress/portfolio/site
	<Directory /mnt/d/Soft/Freelance/Wordpress/portfolio/site>
		Options Indexes FollowSymLinks Includes ExecCGI
		AllowOverride All
		Order allow,deny
		Allow from all
		Require all granted
	</Directory>

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
    
</VirtualHost>

Устанавливаем

sudo apt install -y php php-mysql libapache2-mod-php

Эта установка запустит триггеры, один из которых запустит Apache, теперь он будет на правильном порту, если запуска Apache не произойдет, перезапустим его вручную:

sudo systemctl restart apache2

🌐 ШАГ 3 — WordPress (Apache backend)

Документа root:

/var/www/html
Но выше в конфиге был определен алиас "portfolio", это папка, которая подмонтирована из windows и в ней установлен wordpress.

ШАГ 4 — включить mod_rewrite (нужно для WordPress)

sudo a2enmod rewrite

ШАГ 5 — права доступа (очень важно в WSL)

Иногда Apache не может читать Windows-диск:

sudo chmod -R 755 /mnt/d/Soft/Freelance/Wordpress/portfolio/site

База:

sudo mysql


CREATE USER 'dev'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'dev'@'%';
FLUSH PRIVILEGES;
Пользователь может иметь доступ к базе отвсюду.

Создайте базу данных и восстановите в нее дамп из вашего проекта на Wordpress.

🟨 ШАГ 6 — MariaDB

sudo systemctl enable mariadb
sudo systemctl start mariadb

Проброс порта 3306 наружу (в windows)

Пробрасываем на порт 3307, таким образом в windows может быть экземпляр базы  с портом по умолчанию, а к базе внутри WSL можно будет иметь доступ из таких приложений как DBeaver или MySQL Workbench.
При старте WSL он запускается в собственной сети, IP-адрес может меняться и лучше сделать стартовый скрипт, который будет это учитывать и пробрасывать порт наружу.
🧠 Что это за файл

fix-mysql-port.ps1 — это PowerShell-скрипт, который:

  • берёт актуальный IP WSL
  • пересоздаёт проброс порта 3307 → 3306
  • чтобы не зависеть от смены IP
🥇 ГДЕ СОЗДАТЬ

Создай его в любом удобном месте, например:

D:\Soft\DockerData\Scripts\fix-mysql-port.ps1

👉 главное — чтобы путь был простой

🧪 КАК СОЗДАТЬ
  1. Откройте Блокнот или VS Code
  2. Вставьте код:
$ip = (wsl hostname -I).Trim()

netsh interface portproxy delete v4tov4 listenport=3307 listenaddress=127.0.0.1 2>$null

netsh interface portproxy add v4tov4 `
listenport=3307 listenaddress=127.0.0.1 `
connectport=3306 connectaddress=$ip

Write-Host "WSL MariaDB → localhost:3307 → $ip"

  1. Сохраните как:
fix-mysql-port.ps1

🚀 КОГДА ЕГО ЗАПУСКАТЬ
✔ Вручную (пока проще всего)

Каждый раз:

  • после перезапуска WSL
  • после перезагрузки Windows
  • если не работает порт 3307
👉 запуск:

Откройте PowerShell:

powershell -ExecutionPolicy Bypass -File D:\Soft\DockerData\Scripts\fix-mysql-port.ps1
🧠 ПОЧЕМУ ЭТО НУЖНО

WSL меняет IP:

172.31.x.x → каждый запуск новый

👉 поэтому static portproxy НЕ работает стабильно

🧪 КАК ПРОВЕРИТЬ ЧТО ВСЁ ОК

После запуска скрипта:

netsh interface portproxy show all

Должно быть:

127.0.0.1:3307 → <WSL_IP>:3306

🧠 ВАЖНО (частая ошибка)

❌ НЕ подключайтесь в DBeaver к WSL IP
✔ всегда используйте:

127.0.0.1:3307

🟪 ШАГ 7 — PostgreSQL

sudo systemctl enable postgresql
sudo systemctl start postgresql
Проверка работы базы:
sudo systemctl status postgresql
Как и в случае с mySQL лучше сделать проброс порта наружу с другим номером. Postgres по умолчанию работает на порту 5432, делаем проброс на порт 5433. 
Сначала будет полезно добавить или поменять пароль у пользователя postgres базы:

Зайдите через системного пользователя:

sudo -u postgres psql

Потом:

ALTER USER postgres WITH PASSWORD 'StrongPassword123!';

И сразу:

\password postgres

(введите новый пароль вручную дважды)

Выйти:

\q

По умолчанию Postgres слушает localhost, поэтому нужно поправить конфиги, чтобы проброс порта был успешным.

✅ Проверить в WSL

Выполните:

sudo ss -tulpn | grep 5432

Что должно быть хорошо:
0.0.0.0:5432

или

*:5432

Если плохо:
127.0.0.1:5432

или

localhost:5432

Тогда внешний доступ из Windows через portproxy не работает.

🥇 Как исправить

1. Открыть конфиг PostgreSQL
sudo nano /etc/postgresql/*/main/postgresql.conf

Найдите:

#listen_addresses = 'localhost'

Замените на:

listen_addresses = '*'

2. Разрешить подключение

Откройте:

sudo nano /etc/postgresql/*/main/pg_hba.conf

Добавьте строку:

host all all 172.31.32.1/32 scram-sha-256

(если у вас в Windows есть уже запущенный Postgres и у него адрес именно такой)


3. Перезапустить PostgreSQL
sudo systemctl restart postgresql

🥇 Потом проверить снова

sudo ss -tulpn | grep 5432

Проброс порта:

По аналогии с mySql нужно внести изменения в файл start-dev-db.ps1

Вот полное содержимое файла для обоих серверов баз данных:
$ip = (wsl hostname -I).Trim()

netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=3307
netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=5433


netsh interface portproxy add v4tov4 `
  listenport=3307 listenaddress=127.0.0.1 `
  connectport=3306 connectaddress=$ip

netsh interface portproxy add v4tov4 `
  listenport=5433 listenaddress=127.0.0.1 `
  connectport=5432 connectaddress=$ip

Write-Host ""
Write-Host "Portproxy rules:"
netsh interface portproxy show all


Write-Host ""
Write-Host "Ready:"
Write-Host "MariaDB    -> 127.0.0.1:3307"
Write-Host "PostgreSQL -> 127.0.0.1:5433"

🌐 ШАГ 8 — Nginx (главный вход)

Конфиг:

sudo nano /etc/nginx/sites-available/default

📌 Конфигурация

Примерное содержимое файла:

server {
	listen 8081 default_server;
	listen [::]:8081 default_server;

	root /var/www/html;

	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;

	server_name _;

	location / {
		proxy_pass http://127.0.0.1:8082;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	}

}

Перезапуск Nginx:

sudo systemctl restart nginx

Windows Ubuntu WSL

Windows Ubuntu WSL

Установка Ubuntu через WSL под Windows.

Речь про WSL и дистрибутив Ubuntu.

🧱 ЧАСТЬ 1 — УСТАНОВКА WSL (правильно с нуля)

1. Установить WSL

Откройте PowerShell от администратора:

wsl --install

👉 Это:

2. Перезагрузка

После установки:
👉 обязательно перезагрузи ПК

3. Проверка

wsl -l -v

Ожидаемо:

Ubuntu    Stopped    2

4. Первый запуск Ubuntu

Запусти:

wsl -d Ubuntu

или через меню Пуск

👉 создаёшь:

5. Обновление системы

sudo apt update
sudo apt upgrade -y

⚙️ ЧАСТЬ 2 — ПОДГОТОВКА К ПЕРЕНОСУ НА D:

⚠️ Важно:
По умолчанию Ubuntu хранится на диске C:

Путь выглядит так:

C:\Users\<USER>\AppData\Local\Packages\...\LocalState\

🚚 ЧАСТЬ 3 — ПЕРЕНОС WSL НА ДИСК D (ПРАВИЛЬНЫЙ СПОСОБ)

1. Остановить WSL

wsl --shutdown

2. Экспорт Ubuntu (создание бэкапа)

wsl --export Ubuntu D:\wsl\ubuntu.tar

👉 создаётся резервная копия всей системы

3. Удаление старой Ubuntu из WSL

wsl --unregister Ubuntu

⚠️ Это удаляет привязку к старому ext4.vhdx

4. Импорт Ubuntu на диск D

wsl --import Ubuntu D:\wsl\Ubuntu D:\wsl\ubuntu.tar --version 2

👉 теперь система живёт на D:

5. Проверка

wsl -l -v

📍 ЧАСТЬ 4 — ПРОВЕРКА ПУТИ

Проверьте, где реально хранится система:

Get-ItemProperty HKCU:\Software\Microsoft\Windows\CurrentVersion\Lxss\* |
Select DistributionName, BasePath

👉 должно быть:

D:\wsl\Ubuntu\

🧹 ЧАСТЬ 5 — УДАЛЕНИЕ СЛЕДОВ НА C:

После успешного переноса:

Можно удалить:

C:\Users\<USER>\AppData\Local\Packages\...\LocalState\

(если осталась)

Также удалить архив:

D:\wsl\ubuntu.tar

(если перенос завершён успешно)

🧠 ЧАСТЬ 6 — ЧТО В ИТОГЕ ПОЛУЧАЕТЕ

Было:

Стало:

🚀 ЧАСТЬ 7 — РЕКОМЕНДАЦИИ (ВАЖНО)

После переноса:

включите systemd (для сервера):

sudo nano /etc/wsl.conf

Добавьте:

[boot]
systemd=true

Потом:

wsl --shutdown

Дополнительные сведения.

WSL запускается в окне Power Shell, после запуска вы попадаете в терминал, выйти из терминала можно через команду exit при этом WSL останется работающим, если же окно Power Shell закрыть, то WSL будет остановлен.

Если в системе есть еще установленные дистрибутивы WSL, то дистрибутив Ubuntu может оказаться не основным по умолчанию и команда 

wsl -l -v

может выдать примерно следующее:

NAME                   STATE           VERSION
  *docker-desktop        Stopped         2
  Ubuntu                 Stopped         2
  docker-desktop-data    Stopped         2

Чтобы сделать Ubuntu основным дистрибутивом по умолчанию выполните следующую команду:

wsl --set-default Ubuntu

В разных окнах Power Sell можно несколько раз выполнить команду wsl но среда WSL будет запущена только один раз, все остальные команды откроют терминалы к этой среде.

❌ Остановка WSL

wsl --shutdown

👉 тогда:

🎯 ИТОГ

✔ WSL ставится через wsl --install
✔ Ubuntu создаётся на C по умолчанию
✔ перенос делается через:

Windows Ubuntu WSL

Создание пользователя - администратора

Текущая работа от root в WSL неудобна и рискованна. Лучше создать обычного пользователя devadmin, дать ему sudo-права и перевести dev-среду на него. Создать пользователя admin не получится, так как уже есть группа с таким названием.

🏆 Что важно понять заранее

Не все сервисы нужно “переводить” на пользователя devadmin.

Системные сервисы уже работают правильно:

Это нормально и менять не надо.

Что реально перевести на admin

✔ вход в WSL
✔ твои проекты
✔ MinIO
✔ dotnet run / build / git / npm
✔ домашние папки

🥇 План действий

1. Создать devadmin
2. Дать sudo
3. Сделать default user
4. Перенести dev-файлы
5. MinIO запускать от admin
6. root оставить только для администрирования

🥇 ШАГ 1 — создать пользователя

Сейчас все работает под root, это удобно.

adduser devadmin

Задайте пароль.

🏆 ШАГ 2 — дать sudo права

usermod -aG sudo devadmin

Проверить:

id devadmin

Должно быть:

groups=...,sudo

🏆 ШАГ 3 — проверить домашнюю папку

ls /home

Должно появиться:

administrator
devadmin

🏆 ШАГ 4 — сделать default user для WSL

В Windows PowerShell:

ubuntu config --default-user devadmin

🏆 ШАГ 5 — проверить

Закройте WSL и снова откройте:

wsl -d Ubuntu

Потом:

whoami

Должно быть:

devadmin

🏆 ШАГ 6 — дать доступ к проектам

Если проекты лежат в:

/home/administrator

или на D: — отдельно настроим.

Создайте dev-папки:

mkdir -p /home/devadmin/projects
mkdir -p /home/devadmin/services
mkdir -p /home/devadmin/backups

🏆 ШАГ 7 — MinIO перевести на devadmin

Когда пользователь будет создан:

sudo mkdir -p /home/devadmin/minio-data
sudo mkdir -p /home/devadmin/minio-config
sudo chown -R devadmin:devadmin /home/devadmin/minio-data
sudo chown -R devadmin:devadmin /home/devadmin/minio-config

🧠 Что с nginx/apache/db

Оставляем как есть:

nginx -> www-data
apache -> www-data
MariaDB -> mysql
Postgres -> postgres

Это правильно.


Windows Ubuntu WSL

Что такое WSL

WSL (Windows Subsystem for Linux) — это подсистема Linux внутри Windows, которая позволяет запускать полноценное Linux-окружение без отдельной виртуальной машины.

Что даёт WSL

Linux-команды

Можно выполнять:

ls
grep
find
ssh
curl

как на обычном сервере Ubuntu.

Разработка как на сервере

Если ваш хостинг работает на Ubuntu, то WSL очень удобен:

Продакшен: Ubuntu
Разработка: Ubuntu (WSL)

Меньше различий между средами.

Docker

Большинство разработчиков под Windows используют Docker через WSL.

.NET

Можно поставить Linux-версию SDK:

dotnet --version

и собирать проект так же, как на сервере.

React / Node.js

Обычно работают быстрее и стабильнее в WSL, чем в некоторых конфигурациях Windows.

Как это устроено

В современных версиях используется лёгкая виртуализация.

У WSL есть собственная сеть:

Windows
  172.31.32.1

WSL
  172.31.xx.xx

Именно поэтому вы можете видеть:

cat /etc/resolv.conf
nameserver 172.31.32.1

Это адрес Windows, который виден из WSL.

 

Чем WSL отличается от виртуальной машины

Виртуальная машина

Например, через Oracle VM VirtualBox или VMware Workstation:

Windows
 └─ Полноценная VM
     └─ Ubuntu

Плюсы:

Минусы:

WSL

Windows
 └─ Ubuntu

Плюсы:

Почему VS Code любит WSL

Когда открываете проект через:

Remote - WSL

VS Code устанавливает внутри Linux свой сервер:

~/.vscode-server

Поэтому вы видели каталоги вроде:

~/.vscode-server/data/logs

Именно там лежат логи Copilot и Continue.

 

Windows Ubuntu WSL

Настройка Git в WSL-Ubuntu && Windows

Зайдите в папку проекта.

Проверка версии Git

Чтобы узнать, какая версия Git установлена в Ubuntu:

git --version

(Если нужно обновить Git до актуальной версии в Ubuntu: sudo apt update && sudo apt install git -y).

Проверить, установлена ли утилита GitHub CLI (gh) в вашей системе (в WSL Ubuntu, PowerShell на Windows или Linux), можно с помощью любой из следующих команд:

Проверка версии (Самый простой способ)

Выполните в терминале:

Bash 
gh --version

Проверка пути к исполняемому файлу

Как быстро установить gh, если его нет:

В WSL / Ubuntu:

sudo apt update && sudo apt install gh -y

В Windows (через winget в PowerShell):

winget install --id GitHub.cli

Перед началом работы с репозиторием в GitHub вам нужно к нему подключиться с помощью команды 

gh auth login

Далее последует небольшой диалог, в приведенном примере я использую ключ GitHub для авторизации:

gh auth login
? What account do you want to log into? GitHub.com
? What is your preferred protocol for Git operations on this host? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Paste an authentication token
Tip: you can generate a Personal Access Token here https://github.com/settings/tokens
The minimum required scopes are 'repo', 'read:org', 'workflow'.
? Paste your authentication token: **************************************************
- gh config set -h github.com git_protocol https
✓ Configured git protocol
! Authentication credentials saved in plain text
✓ Logged in as YourGitLogin

Чтобы склонировать репозиторий с GitHub со всеми ветками и полной историей, достаточно выполнить стандартную команду git clone:

git clone git@github.com:username/repository.git

(Или через HTTPS / GitHub CLI, например: gh repo clone username/repository).

Вопреки распространенному заблуждению, стандартный git clone по умолчанию скачивает абсолютно ВСЕ ветки, теги и всю историю проекта.

Однако локально Git сразу создает текстовую указательную ветку только для главной (обычно main или master). Остальные ветки остаются в так называемом режиме отслеживания (remote-tracking branches).

Как увидеть все забранные ветки и работать с ними

1. Посмотреть список всех веток

Перейдите в папку проекта (cd repository) и выполните:

git branch -a

Вы увидите список:

* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/main
  remotes/origin/dev
  remotes/origin/feature-login

Все ветки с префиксом remotes/origin/ уже находятся на вашем компьютере, их не нужно скачивать заново из интернета.

2. Как переключиться на нужную ветку

Чтобы начать работать с любой из локально загруженных веток (например, dev), просто переключитесь на нее:

git checkout dev

(В современных версиях Git также можно использовать git switch dev).

Git автоматически создаст локальную ветку dev, свяжет ее с origin/dev и переключит ваш рабочий каталог.

Если вам нужно гарантированно развернуть ЛОКАЛЬНЫЕ копии ВСЕХ веток сразу

Если ваша цель — не просто скачать проект, а сделать так, чтобы команда git branch (без флага -a) сразу показывала полный список всех веток как локальных, используйте короткий однострочник прямо в терминале:

В WSL / Ubuntu (Bash):

git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done
git fetch --all

В Windows PowerShell:

git branch -r | Where-Object { $_ -notmatch '->' } | ForEach-Object {
    $branch = $_.Trim().Replace('origin/', '')
    git branch --track $branch $_.Trim()
}
git fetch --all

После выполнения этого скрипта каждая удаленная ветка превратится в полноценную локальную ветку.

Рекомендуемый файл .gitignore для проекта в связке с .NET и REACT:

# ==========================================
# .NET / C# (Правила сработают для любой подпапки)
# ==========================================
## --- Build & Output directories ---
bin/
obj/
out/
[Bb]in/
[Ob]j/

## --- Visual Studio & Rider temporary files ---
.vs/
.idea/
*.user
*.userosscache
*.sln.docstates
*.suo
*.userprefs

## --- NuGet Packages & Cache ---
*.nupkg
*.snupkg
**/packages/
project.lock.json
project.assets.json

## --- Local settings & Secrets ---
# Локальные пользовательские конфигурации (раскомментируйте, если не хотите коммитить appsettings.Development.json)
# appsettings.Development.json
# appsettings.*.local.json
secrets.json

## --- Test Results & Coverage ---
[Tt]est[Rr]esult*/
*.coverage
*.coveragexml

# ==========================================
# Node.js / Frontend (Vue, React и т.д.)
# ==========================================
node_modules/
dist/
.npm
*.log

# ==========================================
# Общие временные файлы ОС
# ==========================================
.DS_Store
Thumbs.db

 

 

Установка MinIO

Инструкция по установке под пользователем devadmin в WSL Ubuntu Windows с автозапуском через systemd.

🏆 Что получим

User: devadmin
Data: /home/devadmin/minio-data
Console: http://localhost:9001
API:     http://localhost:9000
Autostart: yes

🥇 ШАГ 0 — зайти под devadmin

Проверьте:

whoami

Должно быть:

devadmin

Если нет:

su - devadmin

🥇 ШАГ 1 — скачать MinIO

wget https://dl.min.io/server/minio/release/linux-amd64/minio

chmod +x minio

sudo mv minio /usr/local/bin/

Проверка:

minio --version

🥇 ШАГ 2 — создать каталоги

mkdir -p /home/devadmin/minio-data
mkdir -p /home/devadmin/minio-config

🥇 ШАГ 3 — создать env файл

nano /home/devadmin/minio-config/minio.env

Вставьте:

MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=StrongPass123!
MINIO_VOLUMES=/home/devadmin/minio-data
MINIO_OPTS=--console-address :9001

Сохраните.

Нужно иметь в виду, что

MINIO_ROOT_USER=admin 

это пользователь-администратор внутри MinIO и к текущему пользователю devadmin отношения не имеет.

🥇 ШАГ 4 — создать systemd сервис

sudo nano /etc/systemd/system/minio.service

Вставьте:

[Unit]
Description=MinIO Object Storage
After=network.target

[Service]
User=devadmin
Group=devadmin
WorkingDirectory=/home/devadmin

Environment="MINIO_ROOT_USER=admin"
Environment="MINIO_ROOT_PASSWORD=StrongPass123!"

ExecStart=/usr/local/bin/minio server /home/devadmin/minio-data --console-address :9001

Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

🥇 ШАГ 5 — включить автозапуск

sudo systemctl daemon-reload
sudo systemctl enable minio
sudo systemctl start minio

🥇 ШАГ 6 — проверить статус

sudo systemctl status minio

Должно быть:

active (running)

🥇 ШАГ 7 — открыть в Windows

Браузер:

http://localhost:9001

Логин:

admin

Пароль:

StrongPass123!

🥇 ШАГ 8 — создать bucket

В UI:

uploads

🧠 Если localhost не открывается

Проверь:

sudo ss -tulpn | grep 900

🏆 После этого можно использовать в .NET

Endpoint: http://localhost:9000
AccessKey: admin
SecretKey: StrongPass123!
Bucket: uploads

🥇 Важно

Если systemd ещё не включён:

sudo nano /etc/wsl.conf

Добавить:

[boot]
systemd=true

Затем из Windows:

wsl --shutdown

 

Настройка VPN через туннель к VPS

Окружение для настройки.

Установка туннеля.

Нужно открыть windows PowerShell от лица администратора. 

В windows PowerShell нужно подключиться к вашему VPS:

ssh -D 0.0.0.0:1080 -N root@[IP_your_vps]

Windows может попросить подтвердить использование туннеля.

Если у вас нет ключа доступа к VPS, то потребуется ввести пароль для root.

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

Откройте другое окно PowerShell с обычными правами. Проверка соединения:

curl.exe --proxy socks5h://127.0.0.1:1080 https://api.ipify.org

Команда должна показать IP вашего VPS.

В настройках Windows есть раздел "proxy" его можно использовать  для включения обмена, но с оговорками. Нужно иметь в виду, что туннель открывается только для протокола socks, для протоколов http и https он не работает. В поле "Proxy IP address"  нужно прописать 

socks=127.0.0.1:1080

в поле для значения порта ничего быть не должно.

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

proxy-2.jpg

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

 Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'

для установки протокола socks:

Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer 'socks=127.0.0.1:1080'

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

Не все приложения Windows используют системный SOCKS-прокси.

Например:

Для включения proxy используйте команду

Set-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable 1

В обычном cmd.exe (или FAR например) аналог делается через reg add.

Включить прокси:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 1 /f

Отключить прокси:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 0 /f

Установить SOCKS-прокси:

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer /t REG_SZ /d "socks=127.0.0.1:1080" /f

Проверить текущие значения:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer

После изменения реестра некоторые программы сразу подхватывают настройки, а некоторые — только после перезапуска. Чтобы уведомить Windows о смене настроек прокси без выхода из системы, можно выполнить:

RUNDLL32.EXE inetcpl.cpl,LaunchConnectionDialog

или просто перезапустить приложение (браузер, VS Code и т.п.).

Пояснения по открытию туннеля от ChatGPT.

Вопрос:

что конкретно делает эта команда ssh -D 0.0.0.0:1080 -N root@[IP_your_vps]

На вашем компьютере запускается локальный SOCKS5-прокси на порту 1080.

Все программы, которые используют этот SOCKS-прокси, будут выходить в интернет через VPS.

Схема:

Приложение
    ↓
SOCKS5 127.0.0.1:1080
    ↓
SSH-соединение
    ↓
VPS
    ↓
Интернет

Разбор параметров

ssh

Запускает SSH-клиент.

root@IP_VPS

Подключается к VPS:

Пользователь: root
Сервер: IP_VPS

Например:

ssh root@38.242.220.114
-D

Означает Dynamic Port Forwarding.

То есть SSH создаёт SOCKS-прокси.

Например:

-D 1080

создаёт:

SOCKS5 localhost:1080

Любая программа, умеющая SOCKS5, может его использовать.

0.0.0.0:1080

Очень важный момент.

Если написать:

-D 1080

или

-D 127.0.0.1:1080

то SOCKS будет доступен только на локальном интерфейсе Windows.

WSL обычно не сможет к нему подключиться напрямую.

Если написать:

-D 0.0.0.0:1080

то SSH слушает на всех интерфейсах:

127.0.0.1
LAN IP
WSL gateway
и т.д.
-N

Означает:

Не запускать shell на VPS

То есть:

❌ не открывать консоль Linux

✅ только держать туннель

Окно просто висит:

ssh -D ...

и прокси работает.

Что НЕ делает эта команда

Она НЕ создаёт полноценный VPN.

Не происходит автоматического перенаправления всего трафика.

Например в WSL:

curl https://api.ipify.org

по умолчанию всё ещё идёт напрямую.

А вот:

curl --proxy socks5h://172.31.32.1:1080 https://api.ipify.org

идёт через VPS.

Чем отличается от VPN

VPN:

Весь трафик
    ↓
VPN
    ↓
VPS

SSH SOCKS:

Только программы,
которые настроены на SOCKS
    ↓
VPS

Почему это удобно

Для связки:

Windows
 └─ WSL
     └─ VS Code
         └─ Continue

достаточно настроить Continue, VS Code или переменные окружения на использование SOCKS.

Тогда:

будут работать через VPS,

а остальной интернет останется обычным.

Для дополнительной безопасности я бы рекомендовал использовать не root, а отдельного пользователя на VPS:

ssh -D 0.0.0.0:1080 -N devadmin@IP_VPS

Это не влияет на работу туннеля, но считается хорошей практикой администрирования.

Работа с MS Vs Code

Настройка, работа в Windows и Linux, подключение AI-агентов и плагинов.

Работа с MS Vs Code

Настройка VS Code для работы в WSL

WSL - это среда Linux под Windows подробнее о WSL.

Для стека Ubuntu-хостинг + .NET 10 + React + SSH-туннели VS Code через WSL обычно удобнее, чем запуск проекта напрямую в Windows.

1. Среда разработки совпадает с сервером

Если у вас продакшен на Ubuntu.

Когда VS Code открыт как:

WSL: Ubuntu

команды выполняются в Linux:

dotnet build
npm install
npm run dev

То есть почти в той же среде, что и сервер.

Меньше сюрпризов вида:

"На Windows работает, а на Ubuntu нет".

2. Лучше работает Node.js и React

Многие инструменты фронтенда изначально ориентированы на Linux/macOS.

Например:

обычно чувствуют себя в WSL стабильнее, чем при работе с проектом на диске Windows.

Особенно это заметно на больших проектах.

3. Нормальные Linux-инструменты

Сразу доступны:

grep
find
sed
awk
ssh
rsync
curl

Не нужно искать Windows-аналоги.

4. Удобнее работать с сервером

Если вы постоянно используете SSH к VPS.

В WSL можно:

ssh server
scp file
rsync project

без дополнительных утилит.

5. AI-инструменты работают рядом с кодом

Когда VS Code открыт в WSL:

VS Code
  ↓
VS Code Server (в WSL)
  ↓
Continue / Copilot
  ↓
Файлы проекта

AI видит проект напрямую в Linux-среде.

6. .NET ближе к реальному продакшену

Если сервер Ubuntu, то:

dotnet publish

в WSL собирает проект в Linux-окружении.

Легче ловить проблемы:

Когда лучше открывать через Windows

Есть случаи, когда удобнее работать напрямую из Windows:

Но если у вас:

React
ASP.NET Core
Ubuntu

то WSL выглядит более естественным вариантом.

Важный момент

Если вы используете WSL, держите проект внутри Linux-файловой системы:

/home/devadmin/projects/myapp

а не в:

/mnt/c/Users/...

На небольших проектах разница может быть незаметна, но на React-проектах с большим количеством файлов производительность и скорость работы инструментов обычно лучше внутри файловой системы WSL.

Для работы в WSL вам нужно выполнить сначала установку VS Code под Windows, скачайте его с официального сайта по ссылке.

После запуска установленного VS Code вам нужно установить расширение WSL. Перейдите на вкладку расширений и в строке поиска наберите:

wsl

В результатах поиска найдите расширение с названием WSL и примерно таким описанием:

Open any folder in the Windows Subsystem for Linux (WSL) and take advantage of Visual Studio Code's full feature set.

Установите это расширение. После установки вы сможете работать с WSL. Для этого нужно сделать к нему подключение. 

Нажмите Ctrl->Alt->O или кликните в нижнем левом углу по иконке "><",откроется Remote Menu, в нем выберите "Connect to WSL", после запуска будет загружен и запущен сервер VS Code в WSL, затем вы сможете работать в проводнике с папками в вашем WSL-хранилище.

Установка плагина Continue и настройка под ним AI-моделей.

 

 

-- Что ниже пока неизвестно, нужно или нет --

Откройте:

nano ~/.bashrc

добавьте в конец:

export ALL_PROXY=socks5://172.31.32.1:1080
export HTTP_PROXY=socks5://172.31.32.1:1080
export HTTPS_PROXY=socks5://172.31.32.1:1080

Сохраните:

Ctrl+O
Enter
Ctrl+X

Применить:

source ~/.bashrc
Для VS Code Remote WSL

В settings.json:

{
    "http.proxy": "socks5://172.31.32.1:1080",
    "http.proxySupport": "override",
    "http.proxyStrictSSL": false
}

После этого:

из WSL будут идти через VPS.

Ваша итоговая схема теперь:

Windows
   |
   | SSH -D 0.0.0.0:1080
   |
   v
VPS (38.242.221.111)
   |
   v
Internet

WSL
   |
   v
172.31.32.1:1080



Настройка SSH для VPS (Windows && Linux-WPS)

Настройка под Windows.

Для настройки соединения у вас обязательно должен быть файл с приватным ключом и желательно с публичным тоже. В моем примере я использую ключи в формате ED25519, которые приходят сейчас на смену ключам RSA. На VPS вы сгенирировали файлы с ключами, в моем случае они назывались id_ed25519 и id_ed25519.pub, лучше их переименовать в виде id_ed25519_myproxy и id_ed25519_myproxy,pub. Если у вас имеется несколько серверов с различными ключами, то названия файлов будут различаться и подключение будет управляться через файл config.

Положите файлы в папку C:\Users\[your_user_name]\.ssh\, в той же папке создайте файл config без расширения примерно с таким содержанием:

Host myproxy
    HostName 11.22.33.44                   # IP-адрес или домен вашего VPS
    User root                              # Логин для подключения
    IdentityFile ~/.ssh/id_ed25519_myproxy # Путь к файлу ключа
    DynamicForward 0.0.0.0:1080            
    IdentitiesOnly yes
    SessionType none
    Port 22                                # Порт (если меняли стандартный)

Строка DynamicForward 0.0.0.0:1080 это прямой аналог флага -D 0.0.0.0:1080 в файле конфигурации. Он включает локальный SOCKS5-прокси на порту 1080 для всех сетевых интерфейсов (0.0.0.0), строка SessionType none это директива RequestTTY no которая аналогична флагу -N и позволяет не выполнять команды на удаленном сервере, а только держать туннель.

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

ssh myproxy
Проверить, открыт ли порт 1080 и слушаются ли на нем подключения, можно прямо из консоли Windows (Command Prompt / PowerShell) или из среды WSL.

Ниже приведено несколько простых способов проверки работает ли соединение.

Способ 1. Проверка через PowerShell (Windows) — Самый удобный

Откройте PowerShell от имени администратора или обычного пользователя и выполните:

PowerShell 
Get-NetTCPConnection -LocalPort 1080 -ErrorAction SilentlyContinue

Способ 2. Классическая команда netstat (Windows CMD / PowerShell)

Откройте командную строку или PowerShell и выполните:

DOS 
netstat -ano | findstr :1080

Способ 3. Проверка через терминал WSL (Linux)

Если туннель или проверяемое приложение запущены внутри WSL, используйте стандартные утилиты Linux:

Bash 
# Через ss (современный аналог netstat)
ss -tulpn | grep 1080

# Или через классический netstat
netstat -tulpn | grep 1080

Способ 4. Экспресс-проверка подключения (Test-NetConnection)

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

PowerShell 
Test-NetConnection -ComputerName 127.0.0.1 -Port 1080
В ответ вы получите отчет. Обратите внимание на нижнюю строку:

Узнать, какая программа заняла порт:
Если порт 1080 занят, но вы не уверены, чем именно, узнайте PID из команды netstat (последнее число в строке) и выполните в PowerShell:
PowerShell
Get-Process -Id <PID>