Установка и настройка nginx на Debian и Ubuntu

Установка nginx занимает тридцать секунд. Остаток дня уходит на то, что серверный блок не срабатывает, PHP отдаёт 502, а порт 80 уже занят Apache. В этой статье разобраны именно эти места, причём отдельно для Debian 13, Debian 12, Ubuntu 24.04 и Ubuntu 22.04: четыре системы ведут себя по-разному сразу в нескольких точках.

Какой nginx выбрать: пакет дистрибутива или официальный репозиторий

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

На самом nginx.org в июле 2026 года доступны ветки 1.30.4 (stable) и 1.31.3 (mainline). Разрыв с Ubuntu 22.04 составляет таким образом около шести лет развития функциональности.

Берите пакет дистрибутива, если вы обслуживаете классические сайты или схемы с reverse proxy и хотите, чтобы работу делал unattended-upgrades. Берите репозиторий nginx.org, если вам нужны HTTP/3 и QUIC (в Ubuntu 22.04 их нет вовсе, в Debian 12 тоже), если вы хотите готовые динамические модули вроде nginx-module-brotli или ACME-модуль, либо если на нескольких дистрибутивах должна работать ровно одна и та же версия.

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

Установка из пакета дистрибутива

На всех четырёх системах одинаково:

apt update
apt install -y nginx
apt install -y curl

Метапакета nginx достаточно. nginx-full и nginx-extras в Debian 12 и 13 по-прежнему существуют, но тянут за собой лишь дополнительные пакеты с модулями. Отдельные модули ставятся адресно, например apt install libnginx-mod-http-headers-more-filter.

curl стоит в списке намеренно. Он не является зависимостью nginx и отсутствует на свежеустановленном Debian или Ubuntu даже после того, как nginx поставился без единой ошибки. Без этого шага первая же проверочная команда ниже оборвётся с curl: command not found, и та же ловушка сработает позже на проверке заголовка Host и на проверке PHP.

Теперь часть, которую большинство руководств пропускает: доказательство того, что всё действительно работает. apt install без сообщений об ошибке не доказывает ничего.

nginx -v
systemctl is-enabled nginx
systemctl is-active nginx
curl -I http://127.0.0.1/

Ожидаются enabled, active и HTTP/1.1 200 OK с заголовком Server, в котором назван nginx (Debian 13 отвечает Server: nginx, Ubuntu 24.04 отдаёт Server: nginx/1.24.0). Только после этого веб-сервер можно считать поднятым. Если нужно узнать, с какими опциями собран пакет, поможет nginx -V (заглавная V): там же видно, включён ли --with-http_v3_module.

Если ufw активен, не хватает ещё правила файрвола. Сначала стоит взглянуть на сам пакет: на Ubuntu Server ufw установлен с завода и просто неактивен, на Debian его нет вообще. Там первый же вызов ответит ufw: command not found. Поэтому установите его заодно, пакет есть на всех четырёх системах:

apt install -y ufw
ufw app list
ufw allow 'Nginx Full'

Профили приносит с собой пакет nginx-common из дистрибутива: Nginx Full, Nginx HTTP и Nginx HTTPS, а на Debian 13 дополнительно Nginx QUIC. При установке из репозитория nginx.org они в ufw app list вообще не появятся (см. таблицу выше).

Подключение официального репозитория nginx

nginx.org поддерживает bookworm, trixie, jammy и noble. apt-key объявлен устаревшим, ключ должен лежать в отдельном keyring и подключаться через signed-by.

apt install -y curl gnupg2 ca-certificates lsb-release debian-archive-keyring

На Ubuntu последний пакет называется ubuntu-keyring, а не debian-archive-keyring. Дальше:

mkdir -p /root/.gnupg && chmod 700 /root/.gnupg
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
gpg --dry-run --quiet --no-keyring --import --import-options import-show /usr/share/keyrings/nginx-archive-keyring.gpg

mkdir в первой строке не балласт. На свежем сервере каталога /root/.gnupg ещё нет, а gpg 2.4.7 из Debian 13 именно в такой комбинации вызовов сам его не создаёт. Проверочная команда тогда обрывается с gpg: Fatal: /root/.gnupg: directory does not exist!, причём посреди вывода, то есть до того, как появятся отпечатки ключей. Чтобы их увидеть, каталог нужно создать заранее, либо один раз выполнить gpg --list-keys.

Последняя команда тоже не украшение, это и есть настоящая контрольная проверка. Она показывает три ключа, так и задумано, прерываться не нужно: текущий ключ подписи 8540 A6F1 8833 A80E 9C16 53A4 2FD2 1310 B49F 6B46 (signing-key-2@nginx.com), а также 573B FD6B 3D8F BC64 1079 A6AB ABF5 BD82 7BD9 BF62 и 9E9B E90E ACBC DE69 FE9B 204C BCDC D8A3 8D88 A2B3. Если отпечатки другие, загрузка вернула не то, что ожидалось, и на этом месте работу нужно прекратить.

Теперь источник пакетов. Обратите внимание на сегмент пути после /packages/: nginx.org держит для Debian и Ubuntu два отдельных дерева каталогов. В /packages/debian/dists/ нет ни noble, ни jammy, пакеты Ubuntu лежат исключительно в /packages/ubuntu/. Приведённый вариант подставляет сегмент сам и поэтому без изменений работает в обоих семействах:

OS=$(. /etc/os-release; echo $ID)
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/$OS $(lsb_release -cs) nginx" | tee /etc/apt/sources.list.d/nginx.list

$ID на Debian равен debian, на Ubuntu ubuntu, так что путь подстраивается под дистрибутив автоматически. Если вместо этого жёстко вписать packages/debian, потому что вы выполняете инструкцию для Debian на системе Ubuntu, echo запишет строку без возражений, а ошибка всплывёт только при следующем apt update:

Err: http://nginx.org/packages/debian noble Release
E: The repository 'http://nginx.org/packages/debian noble Release' does not have a Release file.

На Ubuntu 22.04 в этом месте будет jammy вместо noble, причина та же. Для ветки mainline перед именем дистрибутива добавляется mainline/. Чтобы apt действительно предпочёл пакет с nginx.org пакету дистрибутива, нужен пиннинг, иначе в зависимости от номера версии победит не тот:

printf 'Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n' | tee /etc/apt/preferences.d/99nginx
apt update
apt-cache policy nginx
apt install -y nginx

apt-cache policy nginx это контроль перед установкой: в строке Candidate должна стоять версия с nginx.org (например 1.30.4-1~noble), а приоритетом должно быть значение 900 из файла пиннинга. Если там по-прежнему версия дистрибутива, пиннинг не сработал и вы сразу поставите не тот пакет.

Переход с уже установленного пакета дистрибутива

Если пакет дистрибутива уже работает, обновление сорвётся. Сообщение выглядит примерно так:

dpkg: error processing archive /var/cache/apt/archives/nginx_1.30.4-1~bookworm_amd64.deb (--unpack):
 trying to overwrite '/etc/nginx/mime.types', which is also in package nginx-common 1.22.1-9+deb12u9

Пакет nginx.org не знает про nginx-common, поэтому файлы конфликтуют. Чистый путь: сначала сохранить конфигурацию, затем удалить пакет дистрибутива, затем установить заново.

tar czf /root/nginx-config-backup.tar.gz /etc/nginx
systemctl stop nginx
apt purge -y nginx nginx-common
apt install -y nginx

То, что tar при этом выводит tar: Removing leading '/' from member names, нормально и ошибкой не является. После этого /etc/nginx/sites-available исчезнет, и старые виртуальные хосты останутся только в архиве. Скопируйте их в /etc/nginx/conf.d/ и дайте им расширение .conf, иначе они не загрузятся. Следите при этом за двумя вещами: include snippets/fastcgi-php.conf; в пакете nginx.org не существует, а пользователь процесса теперь называется nginx, что касается прав на файлы и сокетов PHP-FPM.

Как на самом деле работают sites-available и sites-enabled

Модель из двух каталогов придумана в Debian, самому nginx она неизвестна. В /etc/nginx/sites-available/ лежат все файлы конфигурации, в /etc/nginx/sites-enabled/ лежат символьные ссылки на активные из них. Загружается только то, что подключено в nginx.conf через include. Если есть сомнения, проверьте это сами:

grep include /etc/nginx/nginx.conf

В пакете Debian и Ubuntu там две строки, include /etc/nginx/conf.d/*.conf; и include /etc/nginx/sites-enabled/*;. В пакете nginx.org есть только первая. Отсюда и берётся классика жанра: человек выполняет инструкцию для Ubuntu на пакете nginx.org, создаёт /etc/nginx/sites-available/mysite, ставит символьную ссылку, получает от nginx -t чистое syntax is ok, и всё равно ничего не происходит. Сообщения об ошибке нет, потому что этот каталог попросту никого не интересует.

Контрольная проверка, которая всегда говорит правду, это nginx -T с заглавной T. Она выводит полную разобранную конфигурацию, то есть ровно то, что nginx действительно видит:

nginx -T | grep -n "server_name\|listen\|root"

Если вашего server_name в этом выводе нет, файл не читается. Точка. Дальнейшая отладка самой конфигурации в этом случае пустая трата времени.

Вторая частая ошибка — символьная ссылка в пустоту, например после опечатки или после переименования целевого файла:

nginx: [emerg] open() "/etc/nginx/sites-enabled/mysite" failed (2: No such file or directory) in /etc/nginx/nginx.conf:62

Битые символьные ссылки находятся командой find /etc/nginx/sites-enabled/ -xtype l. Отключается сайт, кстати, никогда не удалением файла в sites-available, а удалением ссылки: unlink /etc/nginx/sites-enabled/mysite.

Первый собственный серверный блок

Создадим статический сайт. Сначала каталог и тестовый файл:

mkdir -p /var/www/example/html
echo '<h1>Тестовая страница KernelHost</h1>' > /var/www/example/html/index.html
chown -R www-data:www-data /var/www/example

В пакете nginx.org владельцем будет nginx:nginx. Теперь конфигурация, и это действительно отдельный шаг: файл должен существовать до того, как на него укажет символьная ссылка. Создайте его в редакторе или запишите сразу через heredoc, в пакете nginx.org он вместо этого кладётся в /etc/nginx/conf.d/example.conf:

cat > /etc/nginx/sites-available/example <<'EOF'
server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;
    root /var/www/example/html;
    index index.html;

    access_log /var/log/nginx/example.access.log;
    error_log  /var/log/nginx/example.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}
EOF

Одинарные кавычки вокруг 'EOF' важны, иначе оболочка подставит вместо $uri пустоту и блок окажется сломанным уже в момент сохранения. Только после этого включаем, проверяем и перезагружаем конфигурацию:

ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx

Порядок здесь не произвольный. ln создаёт символьную ссылку и тогда, когда целевого файла не существует, и не говорит об этом ни слова. Вскрывается это только на проверке:

nginx: [emerg] open() "/etc/nginx/sites-enabled/example" failed (2: No such file or directory) in /etc/nginx/nginx.conf:61

Номер строки зависит от системы (61 на Debian 13, 60 на Debian 12 и на обеих Ubuntu), само сообщение одинаково. reload в таком состоянии будет отклонён, то есть работающая конфигурация останется нетронутой. Ровно этот случай находит и find /etc/nginx/sites-enabled/ -xtype l.

Здесь же регулярно всплывают ещё три ошибки.

Дублирующийся сервер по умолчанию. Если скопировать default_server из чужой инструкции, пока стандартная страница Debian ещё активна, получится:

nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/example:2

Либо уберите ключевое слово, либо отключите стандартную страницу командой unlink /etc/nginx/sites-enabled/default.

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

nginx: [warn] conflicting server name "example.com" on 0.0.0.0:80, ignored

Слишком длинное имя сервера. При длинных доменах или большом числе поддоменов:

nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 32

Помогает server_names_hash_bucket_size 64; в блоке http файла nginx.conf.

Проверить работу можно без DNS, через заголовок Host:

curl -H 'Host: example.com' -sS http://127.0.0.1/

Если вместо вашей тестовой страницы придёт стандартная страница Debian, ваш блок не срабатывает и запрос попадает на сервер по умолчанию. Если пришла ваша страница, всё в порядке.

Подключение PHP-FPM

Здесь притаилась самая неприятная ловушка всего руководства, и она стабильно стоит людям часа времени. Метапакет php через php8.x зависит от альтернативы libapache2-mod-php8.x | php8.x-fpm | php8.x-cgi. apt всегда выбирает первую, поэтому apt install php надёжно приносит с собой Apache, а тот занимает порт 80. Поэтому ставьте пакеты адресно:

apt install -y php-fpm php-mysql php-xml php-curl php-mbstring php-zip

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

Не угадывайте путь, посмотрите его:

ls -l /run/php/

Блок PHP внутри server (пример для Debian 12, путь подставьте свой):

    index index.php index.html;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }

На Debian и Ubuntu первые строки можно заменить на include snippets/fastcgi-php.conf;, в пакете nginx.org этого сниппета нет, там нужен развёрнутый вариант. try_files $uri =404; здесь не украшение: он не даёт выполнить загруженные файлы, к пути которых дописано .php.

Не хватает ещё одного шага, и его пропускают почти всегда. Проверочный запрос дальше пойдёт через штатный виртуальный хост по умолчанию, а в /etc/nginx/sites-available/default секция location ~ \.php$ с завода полностью закомментирована. Пока это так, nginx отдаёт файлы .php без обработки: вы получите 200 OK с Content-Type: application/octet-stream и исходный код PHP в открытом виде. Это не косметический недочёт. В настоящем файле в этом месте стоят доступы к базе данных или API-ключи, и их прочитает каждый, кто знает URL.

Поэтому сначала активируйте блок. Уберите в /etc/nginx/sites-available/default символы комментария перед ним или впишите его целиком:

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
    }

Имя сокета зависит от дистрибутива, таблица выше его называет: php8.4 на Debian 13, php8.3 на Ubuntu 24.04, php8.2 на Debian 12, php8.1 на Ubuntu 22.04. После этого проверяем и перезагружаем конфигурацию:

nginx -t
systemctl reload nginx

Только теперь проверка имеет смысл и показывает, что PHP действительно исполняется через FPM, а не просто предлагается на скачивание:

printf '<?php echo "PHP ", PHP_VERSION, " via ", php_sapi_name(), "\n";' > /var/www/html/kh-check.php
curl -s http://127.0.0.1/kh-check.php
rm /var/www/html/kh-check.php

Правильный вывод выглядит как PHP 8.4.23 via fpm-fcgi, на Ubuntu 24.04 соответственно PHP 8.3.6 via fpm-fcgi. Если вместо этого вернулся исходный код, location ~ \.php$ в активном виртуальном хосте ещё не работает: он либо по-прежнему закомментирован, либо указывает на неверный сокет. Не забудьте удалить файл и не используйте phpinfo() на сервере, доступном извне.

Как правильно читать 502 Bad Gateway

Код 502 сам по себе не диагноз, диагноз стоит в /var/log/nginx/error.log. Типичных строк три:

connect() to unix:/run/php/php8.2-fpm.sock failed (2: No such file or directory) while connecting to upstream

Неверный путь или FPM не запущен. Проверьте через systemctl status php8.2-fpm и ls /run/php/. Частая причина это обновление дистрибутива: после перехода с Debian 12 на 13 старая конфигурация всё ещё указывает на php8.2-fpm.sock, а установлена уже версия 8.4.

connect() to unix:/run/php/php8.2-fpm.sock failed (13: Permission denied) while connecting to upstream

Это касается почти исключительно установок из репозитория nginx.org. Пул FPM принадлежит www-data и имеет режим 0660, а nginx работает там от пользователя nginx. Задайте в /etc/php/8.2/fpm/pool.d/www.conf значение listen.group = nginx и перезапустите FPM.

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream

SCRIPT_FILENAME указывает в пустоту. Чаще всего root стоит в блоке location вместо блока server или отсутствует вовсе.

HTTPS с Let's Encrypt

Версии certbot в дистрибутивах расходятся сильно: Debian 13 поставляет 4.0.0, Ubuntu 24.04 версию 2.9.0, Debian 12 версию 2.1.0, а Ubuntu 22.04 всего лишь 1.21.0. ACMEv2 понимают все, но для новых возможностей вроде короткоживущих сертификатов версия 1.21 уже слишком стара. На Ubuntu 22.04 имеет смысл обходной путь через snap.

apt install -y certbot python3-certbot-nginx
certbot --version

Перед выпуском сертификата должны выполняться три условия, иначе проверка провалится без внятного сообщения: A-запись (и при необходимости AAAA) указывает на сервер, порт 80 доступен снаружи, и существует серверный блок с подходящим server_name. Последний пункт решающий, потому что плагин nginx находит блок по server_name, а не по имени файла. Дальше:

certbot --nginx -d example.com -d www.example.com

После этого certbot пишет в ваш файл конфигурации: второй серверный блок с listen 443 ssl, пути к fullchain.pem и privkey.pem, строку include /etc/letsencrypt/options-ssl-nginx.conf и переадресацию с порта 80. То, что файл при этом изменяется, регулярно застаёт врасплох. Если потом перезаписать его вручную, HTTPS будет потерян, а при следующей перезагрузке конфигурации появится:

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": BIO_new_file() failed

Автоматическое продление работает через таймер systemd, а не через cron-задание. Проверьте и то, и другое:

systemctl list-timers | grep certbot
certbot renew --dry-run

Тестовый прогон — единственное настоящее доказательство того, что продление сработает через девяносто дней. Если вы используете репозиторий nginx.org, то начиная с nginx 1.29 есть ещё вариант вообще без certbot: модуль nginx-module-acme, с которым nginx сам запрашивает и обновляет сертификаты.

nginx -t, reload и restart

Правило простое и всё равно постоянно нарушается: никогда не выполнять reload без предварительного nginx -t. При синтаксической ошибке nginx, правда, откажется применять сломанную конфигурацию, но при restart старый процесс уже завершён и сайт лежит.

nginx -t

Ожидается ровно это:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

reload запускает новые рабочие процессы с новой конфигурацией и даёт старым доработать уже открытые соединения. Не теряется ни один запрос. restart нужен только тогда, когда меняется что-то в самом процессе, например после обновления пакета, при смене user или при подгрузке директив load_module.

Если запуск сорвался, вывод systemd почти бесполезен:

Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.

Полезный текст находится уровнем ниже:

journalctl -xeu nginx.service --no-pager -n 30

Как разрешить конфликт за порт 80 с Apache

Самая известная ошибка nginx вообще:

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

Обратите внимание: nginx -t эту ошибку не находит, тест не занимает порты. Срывается только запуск. Сначала выясните, кто держит порт, вместо того чтобы гадать:

apt install -y iproute2
ss -tlnp | grep ':80'

Вывод называет процесс прямым текстом, обычно users:(("apache2",pid=612,fd=4)). В девяти случаях из десяти Apache попал в систему через apt install php или вместе с панелью управления. Есть три чистых выхода.

Первый: выключить Apache. Если он вам не нужен, достаточно его отключить, чтобы он не вернулся после следующей перезагрузки:

systemctl disable --now apache2
systemctl start nginx

Второй: удалить Apache. Внимание: если на нём висит libapache2-mod-php, то apt purge apache2 при некоторых условиях заберёт с собой и PHP. Проверьте список, который apt показывает перед выполнением, и доустановите затем php-fpm.

Третий: работать с обоими параллельно. Это разумно, если существующие виртуальные хосты Apache с .htaccess должны продолжать работать, а nginx стоит перед ними как reverse proxy. Для этого впишите в /etc/apache2/ports.conf строку Listen 127.0.0.1:8080, замените в каждом виртуальном хосте <VirtualHost *:80> на <VirtualHost *:8080> и настройте проксирование в nginx:

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

Чтобы Apache видел в своих логах не только 127.0.0.1, включите в нём модуль remoteip. Без этого шага правила Fail2ban по логам Apache бесполезны, потому что каждый запрос выглядит приходящим с localhost.

Два варианта той же ошибки часто упускают из виду. Если в двух ваших собственных файлах дважды стоит одна и та же запись listen, nginx точно так же сообщит Address already in use, хотя никакого Apache здесь и близко нет. А при bind() to [::]:80 failed затронут только IPv6, чаще всего потому, что второй блок тоже задаёт listen [::]:80 без ipv6only=on.

Приёмка: восемь проверок вместо интуиции

Прежде чем считать установку завершённой, пройдите по этим пунктам. Каждый из них уже когда-то предотвратил тихий отказ.

1. nginx -t сообщает test is successful.
2. systemctl is-enabled nginx возвращает enabled, то есть служба поднимется и после перезагрузки.
3. ss -tlnp | grep nginx показывает порт 80 и, если он настроен, порт 443.
4. nginx -T | grep server_name перечисляет каждый домен, который должен работать.
5. curl -I http://127.0.0.1/ отдаёт 200 или запланированную переадресацию.
6. Тестовый файл PHP выводит fpm-fcgi и после этого удалён.
7. certbot renew --dry-run проходит без ошибок.
8. /var/log/nginx/error.log после тестового обращения не содержит новых записей.

На свежеустановленном сервере следом идёт ещё файрвол, об этом наше руководство по настройке ufw. Debian 10 и Ubuntu 20.04 остались без поддержки с июня 2024 и мая 2025 года соответственно и обновлений безопасности для nginx больше не получают: обновление системы там не вопрос удобства, а давно назревшая необходимость.

Что к этому добавляет KernelHost

На KVM root-серверах и выделенных серверах KernelHost вы устанавливаете Debian 13, Debian 12, Ubuntu 24.04 или Ubuntu 22.04 прямо из личного кабинета и сразу получаете полный root-доступ, все описанные выше шаги работают без изменений. Системы стоят в дата-центре maincubes во Франкфурте-на-Майне, сертифицированном TÜV по TIER3+, и подключены через нашу собственную сеть. Защита от DDoS при этом срабатывает перед сервером, а не только в nginx: 3,2 Тбит/с фильтрации Arbor в реальном времени прямо на площадке, а в тарифах Professional дополнительно до 17 Тбит/с глобальной фильтрующей ёмкости. Всё работает по модели PrePaid, то есть без минимального срока, без срока расторжения и без платы за подключение.