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

За прошедший год с разных сторон я многократно слышал «ты же айтишник, чего не развернешь себе свой сервер с...PN? для себя, для семьи, ну и с друзьями поделился бы».

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

Но маразм крепчал. Причем со всех сторон. Дело даже вообще не в спорном политическом контенте. К примеру, из РФ уже нельзя почитать форумы FreeCAD и LightBurn, которые частенько нужны для моей хоббийной движухи...

Короче, хватит это терпеть. В статье расскажу, как решаю вопросы конфигурирования такого личного сервера. Но не в контексте конкретных конфигураций, а о том, как я использую нейросети для этой дичи. Начну с простых вопросов к Qwen, продолжу уже более комплексно в Cursor AI.

Бегло погуглив, не нашел подобных экспериментов в сети. Возможно чтение этой статьи натолкнет вас на новые мысли по еще более нетрадиционному использованию инструментов ИИ-разработки. Infrastructure as Code! ?

В этой статье я буду нещадно расставлять точечки в спорных названиях. С целью не допустить блокировки в РФ. Потому что статья совсем не про обход блокировок, а про новый подход к использованию нейросетей для конфигурирования серверов.

Легенда: ? – я (бородатого смайла не нашел), ? – бездушная машина.

Шаг 1. Получаем инструкцию от Qwen3-Max

?
напиши актуальную инструкцию, как настроить серверную часть ...ray на debian 13

?
На момент января 2026 года официального релиза Debian 13 (Trixie) ещё не существует — последняя стабильная версия Debian — Debian 12 (Bookworm). Debian 13 находится в стадии разработки и, скорее всего, вышла только в виде testing/unstable или ещё не выпущена.

Здесь Qwen3-Max конечно же врёт. Релиз Debian 13 Trixie вышел 9 августа 2025.

Однако инструкция по установке и настройке ...ray на Debian 12 Bookworm (или любой современной версии Debian, включая будущую 13) будет полностью актуальной, так как ...ray — это статически скомпилированное приложение, не зависящее от большинства системных библиотек.

Ниже — актуальная, безопасная и проверенная инструкция по развёртыванию ...ray сервера на Debian (включая будущую Debian 13), с использованием <skip>, что обеспечивает максимальную совместимость и устойчивость.

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

В итоге получил работающий коннект со смартфона и ноутбука.

Но пока не получилось настроить fallback – веб-страничку, которая бы отдавалась юзерам и маскировала сервер от быстрого обнаружения. Плюс позже веб-сервер мне понадобится для дальнейших экспериментов. Уже не с ...PN.

Шаг 2. Загоняем /etc в git-репозиторий

Создаем пустой приватный репозиторий. Например на GitLab.

На сервере выполняем примерно такие команды:

cd /etc
git remote add origin https://gitlab.com/folder/project.git
git branch -M main
git push -uf origin main

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

У меня это сейчас просто сервер для экспериментов. Поэтому я не стал ограничивать в .gitignore сохранение в репозитории файлов с секретами – паролей, ключей, сертификатов и тому подобного.

Это плохая практика. Не следует повторять ее, если вы не уверены в своих действиях.

Шаг 3. Вайб-админим с Cursor AI

Cursor AI – среда разработки, которая умеет вносить изменения сразу в множество файлов проекта, держа все их в своем контексте. Штатный сценарий использования – программирование.

Но чем наша папка с конфигурациями сервисов сервера отличается от папки с исходным кодом какого-то проекта? Для нейросети – ничем особенным. Это тоже куча текстовых файлов, объединенных для достижения какой-то цели. И заполняемых по каким-то вполне себе известным (нейросети) правилам.

Клонируем репозиторий с конфигами на локальную машину. Открываем эту папку в окне Cursor AI.

Для начала дадим Курсору понять, как именно нетрадиционно мы собираемся его использовать. Чтобы особо не удивлялся. И не сопротивлялся.

?
давай добавим правило cursor о том, что этот репозиторий - папка /etc с сервера debian 13. и что не надо писать readme всякие, а надо в чате писать информацию.

Курсор очень любит плодить всякую новую документацию в md-формате. Лично мне на сервере не нужно это добро, поэтому прошу его так не делать.

?
Создам файл .cursorrules с правилами для этого репозитория:

# Repository Context

This repository contains the `/etc` directory from a Debian 13 server.

## Rules

- This is a system configuration backup, not a development project
- DO NOT create README files, documentation files, or any other explanatory files
- Provide all information, explanations, and documentation in the chat only
- When making changes, focus on system configuration files (nginx, ssh, systemd, etc.)
- Respect the existing file structure and permissions expectations for `/etc`

?
Готово! Создал файл .cursorrules в корне репозитория со следующими правилами:
– Указал, что это директория /etc с сервера Debian 13
– Запретил создание README и других документационных файлов
– Настроил вывод всей информации только в чат
– Добавил контекст для работы с системными конфигурационными файлами

Теперь при работе с этим проектом Cursor будет понимать, что это системная конфигурация, а не обычный код проект, и не будет предлагать создавать README или другие вспомогательные файлы.

?
ты где создал этот файл? вроде нужно в отдельной папке такое делать?

?
Нет, я создал правильно! Файл .cursorrules должен находиться в корне проекта, именно там, где я его и создал. Это стандартное расположение для правил Cursor. Файл работает на уровне всего проекта/репозитория. Возможно, вы думали о папке .cursor/, но она используется для других целей (кеш, настройки IDE), а правила проекта именно в .cursorrules в корне.

Тут, похоже, Курсор врет сам про себя. Но я не буду пока с ним спорить. Понаблюдаю. Может и так сойдет.

В новых версиях Курсора правила должны лежать в отдельной папке:

.cursor/rules/
my-rule/
RULE.md # Main rule file
scripts/ # Helper scripts (optional)

?
задай вопросов, предложи еще какие-то правила

?
Отличная идея! Вот несколько вопросов для улучшения правил:

Вопросы:
– Язык общения: Всегда на русском, или можно на английском для технических терминов?
– Чувствительные данные: Видно что есть сертификаты, ...ray config. Нужно ли добавить правило о предупреждении при работе с такими файлами?
– Проверка синтаксиса: Нужно ли автоматически предлагать проверить синтаксис после изменений в nginx/ssh/systemd конфигах?
– Комментарии: Сохранять все существующие комментарии в конфиг-файлах или можно удалять лишние?
– Приоритетные сервисы: Какие сервисы самые важные? Вижу nginx, ...ray, ssh - что еще критично?
– Бэкапы: Нужно ли предлагать создавать .bak файлы перед изменением критичных конфигов?

Предлагаю добавить правила:

- Always communicate in Russian in chat
- Preserve original comments in configuration files unless explicitly asked to remove
- Warn about potentially dangerous changes (ssh security, nginx syntax, systemd services)
- Never commit passwords, private keys, or sensitive tokens in plain text
- After modifying configs, suggest syntax validation commands (nginx -t, sshd -T, etc.)
- Prioritize safety: explain impact before applying changes to critical services (nginx, ssh, ...ray, systemd)
- Keep file permissions context in mind when suggesting changes

Что из этого добавить? Или есть другие специфичные требования для вашего сервера?

?
давай добавим это

?
Готово! Добавил все предложенные правила в .cursorrules. Теперь файл содержит:

✅ Основные правила - про отсутствие README, вывод в чат
✅ Коммуникация - общение на русском
✅ Безопасность - предупреждения о рискованных изменениях, защита чувствительных данных
✅ Проверка синтаксиса - предложения по валидации конфигов
✅ Сохранение комментариев - не удалять существующие комментарии
✅ Контекст прав доступа - помнить о permissions

Теперь при работе с этим проектом Cursor будет следовать всем этим правилам автоматически!

?
язык - термины можно английским
сертификаты оставляем, так как это в том числе бакап. если сервер отключится, чтобы можно было развернуть на другом хостинге.
приоритетные сервисы правильные, позже добавится django
бэкапы можно не делать, ведь вся конфигурация уже в git. можно будет откатить

?
Обновил правила! Теперь учтены все нюансы:

✅ Язык - русский, но technical terms можно на английском
✅ Сертификаты - сохраняются как часть бэкапа для быстрого разворачивания
✅ Приоритетные сервисы - nginx, ssh, ...ray, systemd, django (будет позже)
✅ Бэкапы - не нужны, есть git для откатов

# Repository Context

This repository contains the `/etc` directory from a Debian 13 server.

## Rules

- This is a system configuration backup, not a development project
- DO NOT create README files, documentation files, or any other explanatory files
- Provide all information, explanations, and documentation in the chat only
- When making changes, focus on system configuration files (nginx, ssh, systemd, etc.)
- Respect the existing file structure and permissions expectations for `/etc`

## Communication and Safety

- Always communicate in Russian in chat (technical terms can be in English)
- Preserve original comments in configuration files unless explicitly asked to remove
- This is a full backup including certificates - needed for quick deployment on new hosting
- Warn about potentially dangerous changes (ssh security, nginx syntax, systemd services)
- After modifying configs, suggest syntax validation commands (nginx -t, sshd -T, etc.)
- Priority services: nginx, ssh, ...ray, systemd, django (upcoming)
- No need for .bak files - all configuration is version controlled in git
- Keep file permissions context in mind when suggesting changes

Отличная стратегия - весь /etc в git позволяет быстро восстановить сервер на новом хостинге со всеми настройками и сертификатами. Infrastructure as Code! ?

Однако, ему самому нравится :) Пожалуй, вынесу эту его фразу в тизер...

?
у меня сконфигурирован ...ray сервер. я пытался настроить выдачу nginx для маскировки, но почему-то fallback не работает. можешь разобраться, почему?

?
Давайте разберёмся с проблемой fallback между ...ray и Nginx. Мне нужно посмотреть конфигурации обоих сервисов. Вижу проблему! Nginx настроен слушать на порту 8080, что правильно для fallback схемы. Теперь мне нужно посмотреть конфигурацию ...ray, чтобы проверить настройки fallback.

Похоже, конфигурационный файл ...ray (/usr/local/etc/...ray/config.json) не был скопирован в этот репозиторий. Можете скопировать сюда содержимое файла /usr/local/etc/...ray/config.json с сервера? Или если у вас есть доступ к серверу, выполните: cat /usr/local/etc/...ray/config.json

А пока могу предположить типичные проблемы с fallback: <skip>

Тут меня ткнули носом в то, что конфиг ...ray лежит за границами папки /etc, а значит – его нет в репозитории.

Скопировал на сервере конфиг в /etc/...ray, сделал из оригинальной локации симлинк на этот конфиг. Чтобы он тоже обновлялся через git.

?
добавил конфиг ...ray. изучи его и скажи, что не так

?
Нашёл проблему! У вас критическая несовместимость в конфигурации ...ray. Проблема в том, что:

❌ Проблема #1: WebSocket + Fallback несовместимы. Fallback не работает с WebSocket! Fallback работает только с протоколом TCP.

❌ Проблема #2: Неправильный формат dest. Должно быть "dest": "127.0.0.1:8080" (строка, а не число).

✅ Решение: Выберите один из вариантов:

Вариант А: Использовать Fallback (рекомендуется для маскировки). ...ray принимает ВСЕ соединения на 443, а неправильные отправляет в Nginx: <skip>

Вариант Б: Nginx + WebSocket прокси (текущий подход). Nginx на 443 порту, проксирует WebSocket путь на ...ray: <skip>

Nginx конфиг: <skip>

...ray конфиг: <skip>

? Что рекомендую?

Вариант А (Fallback с TCP) - проще и надёжнее для вашего случая. ...ray сам управляет TLS и отправляет "плохие" запросы в Nginx.

Хотите, я исправлю конфигурацию ...ray на Вариант А?

?
нужен вариант с вебсокетами, так как он надежнее с ...pi. то есть наоборот должен nginx проксировать в xray ?

?
Точно! Вариант Б - правильный для WebSocket и ...PI. Сейчас исправлю оба конфига.

Схема:
1. Nginx на 443 → принимает все запросы, SSL/TLS, маскировка
2. Обычные запросы → отдаёт статику (выглядит как обычный сайт)
3. WebSocket путь /api/v.../... → проксирует в ...ray
4. ...ray на локальном порту → без SSL, только WebSocket

✅ Готово! Исправил оба конфига

? Что изменилось:

...ray (/usr/local/etc/...ray/config.json):
✅ Теперь слушает на 127.0.0.1:10000 (только локально)
✅ Убрал SSL/TLS настройки (их обрабатывает Nginx)
✅ Убрал fallbacks (не нужны для WebSocket)
✅ Оставил WebSocket с путём /api/v.../...

Nginx (/etc/nginx/sites-available/default):
✅ Слушает на порту 443 с SSL
✅ Использует Let's Encrypt сертификаты
✅ Обычные запросы → статика (маскировка)
✅ Путь /api/v.../... → проксирует WebSocket в ...ray на порт 10000
✅ Добавил редирект HTTP → HTTPS

? Как это работает:
1. Браузер/клиент → https://somedomain.com → Nginx (443)
2. Обычный HTTP запрос → Nginx отдаёт статику (/var/www/html)
3. ...PN клиент → wss://somedomain.com/api/v.../... → Nginx проксирует в ...ray
4. ...ray (10000) → обрабатывает WebSocket, расшифровывает трафик

Теперь с точки зрения ...PI это выглядит как обычный HTTPS сайт с WebSocket соединением! ?

В целом, после этого направление ...PN заработало как следует. Остался еще момент с CDN, который у меня пока не получилось решить. Но, так как я не собираюсь заниматься каким-то массовым сервисом в этой спорной теме, надеюсь, что CDN мне и не понадобится.

?
давай сделаем для nginx приличную заставку. сгенерируй вместо стандартной его заставки текстовой. проект будет называться "Старт.Электроника". типа разрабатываемый интернет-магазин по продаже электронных компонентов

?
Отлично! Создам красивую стартовую страницу для проекта "Старт.Электроника". Сначала посмотрю текущую конфигурацию nginx, чтобы понять, где размещать файлы.

Вижу, что root настроен на /var/www/html. Создам красивую современную страницу для "Старт.Электроника". Сделаю её прямо в корне вашего проекта как index.html, чтобы вы могли её скопировать в /var/www/html.

Тут я опять понял, что в моем репозитории "чего-то не хватает" ). А именно – папки /var/www/html от веб-сервера.

Отлично! Я создал красивую современную стартовую страницу для проекта "Старт.Электроника". ?

Страница включает:

✨ Дизайн:
– Современный градиентный дизайн с анимациями
– Адаптивная верстка для мобильных устройств
– Плавные переходы и эффекты при наведении
– Фоновая анимация в стиле электронных схем

? Контент:
– Яркий заголовок с иконкой молнии
– Статус "Сайт находится в разработке"
– Три ключевые фичи: ассортимент, цены, доставка
– Информация о проекте
– Контактный email

? Чтобы применить страницу:
Скопируйте файл index.html на ваш сервер. После этого при заходе на ваш домен somedomain.com будет отображаться красивая страница интернет-магазина электронных компонентов вместо стандартной заставки nginx! ?

?
давай положим html внутрь папки nginx

?
Готово! ✅ Я создал папку nginx/html и переместил туда файл index.html. Теперь структура выглядит так:

nginx/
  ├── html/
  │   └── index.html  <-- ваша страница здесь
  ├── sites-available/
  │   └── default
  └── ... (другие конфигурационные файлы)

Для применения на сервере теперь можно скопировать html в /var/www/html/index.html. Или скопировать всю папку html целиком, если планируете добавить больше файлов (CSS, JS, изображения и т.д.).

?
как добавить ssh-ключ, чтобы без ввода пароля можно было коннектиться к этой машине

?
Скопировать ваш публичный ключ на сервер

ssh-copy-id user@server_ip

?
а если у меня есть несколько ключей на компе, как указать нужный?

?

ssh-copy-id -i ~/.ssh/имя_ключа.pub user@server_ip

?
при коннекте по ssh получаю ошибку не фатальную, как ее устранить?

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

?
Это происходит потому что ваш Mac передаёт локаль UTF-8 на сервер, а там её нет.

Решение 1: На сервере (рекомендую)

# Сгенерировать нужные локали
sudo locale-gen en_US.UTF-8
sudo update-locale

Решение 2: На вашем Mac <skip>

Или разово при подключении: <skip>

Первый способ правильнее - на сервере должны быть настроены локали.

?
update-locale выдал ошибки:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_CTYPE = "UTF-8",
	LC_NUMERIC = (unset),
	LC_COLLATE = (unset),
	LC_TIME = (unset),
	LC_MESSAGES = (unset),
	LC_MONETARY = (unset),
	LC_ADDRESS = (unset),
	LC_IDENTIFICATION = (unset),
	LC_MEASUREMENT = (unset),
	LC_PAPER = (unset),
	LC_TELEPHONE = (unset),
	LC_NAME = (unset),
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").

?
Проблема: Mac передаёт LC_CTYPE="UTF-8" вместо правильного LC_CTYPE="en_US.UTF-8"

Решение на сервере:

# Установить правильную локаль
sudo dpkg-reconfigure locales
# Выберите en_US.UTF-8 (пробелом), потом OK

# Или просто:
sudo locale-gen en_US.UTF-8
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8

# Переподключитесь

Или на вашем Mac: <skip>

Перезайдите по SSH - предупреждений не будет. Первый способ (на сервере) правильнее, но второй быстрее.

?
надо решить на сервере. команда выдает ту же ошибку

?
Да, команда сама выдаёт ошибку из-за локали. Делаем так:

# 1. Временно отключить проблемную переменную
unset LC_CTYPE

# 2. Теперь сгенерировать локали
sudo locale-gen en_US.UTF-8

# 3. Обновить конфигурацию
sudo update-locale LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8

# 4. Применить для текущей сессии
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8

# 5. Выйти и зайти заново
exit

При новом подключении ошибки не будет. Если всё равно проблема - проверьте что на сервере в /etc/ssh/sshd_config:

grep AcceptEnv /etc/ssh/sshd_config

Если там AcceptEnv LC_* - можно закомментировать эту строку и перезапустить sshd:

sudo systemctl reload sshd

?
не помогло. проверь сам, что есть в /etc - у тебя полный доступ к этой папке - это репозиторий

Этот диалог был до cursorrules. В статье я поменял порядок. Видно, что без явного указания правил Курсор забывает, что сам репозиторий – это папка /etc.

?
Нашёл! В sshd_config строка 114:

AcceptEnv LANG LC_* COLORTERM NO_COLOR

Это заставляет сервер принимать локали от клиента (вашего Mac), а Mac отправляет кривую LC_CTYPE=UTF-8. Исправил! Убрал LC_* из AcceptEnv, оставил только LANG COLORTERM NO_COLOR.

Применить на сервере:

# Проверить конфиг
sudo sshd -t

# Перезагрузить SSH (без разрыва текущего соединения)
sudo systemctl reload sshd

# Выйти и зайти заново
exit

Теперь сервер не будет принимать LC_CTYPE от Mac, и будет использовать свою локаль en_US.UTF-8 из /etc/locale.conf.

Ошибка исчезнет! ?

?
ура, помогло

?
Отлично! ?

Теперь SSH подключение без предупреждений о локали. Сервер использует свою правильную локаль en_US.UTF-8, а не пытается принять кривую LC_CTYPE=UTF-8 от Mac.

Если что ещё понадобится по настройке сервера - пишите! ?

Таким образом, с помощью Курсора вполне можно получить достаточное количество пользы для конфигурирования Linux-сервера. Без обычного гугления и траты кучи времени. Вайб-администрирование, однако.

Если вам зашла эта статья – предлагаю заглянуть в мой небольшой ТГ-канал @itmancan. Там я не только изредка делюсь своими находками в области ИИ, но и регулярно спасаюсь от айти-выгорания с помощью 3д-проектирования и последующей лазерной резки напроектированного.

Чуть позже в телеге выложу подробности, как была сгенерирована заглавная картинка к этой статье.