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

✉️ Email: [email protected]
📲 Telegram канал: https://t.me/zer0kernelorg
💰 Donate (BTC): bc1qwvrgka76eeley8feqdxjxk2866sv0tnweylxjc
ngx_http_limit_req_module и ngx_http_limit_conn_module встроены в Nginx по умолчанию и не требуют дополнительных пакетов. Они решают две разные задачи: limit_req ограничивает частоту запросов от одного клиента, limit_conn — количество одновременных соединений. Вместе они закрывают основные сценарии: перебор паролей, агрессивный парсинг, всплески трафика от ботов и исчерпание пула соединений к backend.10r/s Nginx пропускает один запрос каждые 100 мс. Если запросы приходят чаще, они либо ставятся в очередь (при наличии burst), либо сразу получают отказ. Очередь тоже ограничена — её размер задаётся параметром burst.limit_req_zone объявляет область в разделяемой памяти, где хранятся счётчики. Размещается в контексте http.http {
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;
}
| Параметр | Назначение |
|---|---|
$binary_remote_addr | Ключ, по которому ведётся подсчёт. Бинарное представление IP занимает 4 байта (IPv4) или 16 байт (IPv6), что экономит память по сравнению с $remote_addr. |
zone=req_per_ip:10m | Имя зоны и размер разделяемой памяти. 1 МБ хранит примерно 16 000 состояний. |
rate=10r/s | Скорость «утечки». Допустимы r/s (запросы в секунду) и r/m (запросы в минуту). |
$server_name для ограничения на весь виртуальный хост, $http_x_api_key для ограничения по API-ключу или комбинацию через конкатенацию.limit_req...docker0 с подсетью 172.17.0.0/16. Каждый контейнер, запущенный без явного указания сети, подключается к этому мосту и получает IP из этой подсети.| Возможность | Default bridge (docker0) | User-defined bridge |
|---|---|---|
| Связь по IP | Да | Да |
| DNS-резолвинг по имени контейнера | Нет | Да |
| Автоматическое подключение | Да | Нет, нужно указать явно |
| Изоляция между контейнерами | Все видят всех | Только контейнеры в одной сети |
127.0.0.11 внутри контейнера), который резолвит имена контейнеров в их текущие IP.## Создание сети
docker network create myapp
## Запуск контейнеров в этой сети
docker run -d --name backend --network myapp nginx
docker run -d --name frontend --network myapp alpine sleep 3600
## Из контейнера frontend имя backend резолвится в его IP
docker exec frontend ping backend
frontend обратится к backend по имени — Docker...shared_buffers = 16GB
restart, не reload).mmap с флагом MAP_SHARED, а не System V shared memory. Поэтому параметры kernel.shmmax и kernel.shmall на современных версиях не влияют на выделение этого буфера. Они могут быть релевантны только при использовании очень старых версий PostgreSQL или нестандартных сборок.location с директивой proxy_pass:server {
listen 80;
server_name example.com;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
example.com на локальный сервис, слушающий порт 8080. Однако без дополнительных директив backend получит искажённую информацию о клиенте.Host на значение из proxy_pass (в примере выше — 127.0.0.1:8080). Backend, который использует Host для маршрутизации или генерации ссылок, получит неверные данные.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;
}
| Заголовок | Что передаёт | Зачем нужен |
|---|---|---|
Host | Оригинальный домен из запроса клиента | Виртуальный хостинг, генерация абсолютных URL |
X-Real-IP | IP-адрес непосредственного клиента | Логирование, rate limiting, геолокация |
X-Forwarded-For | Цепочка IP через все прокси | Аудит, определение источника при нескольких hop'ах |
X-Forwarded-Proto | Протокол оригинального соединения (http или https) | Корректная генерация redirect'ов, проверка secure cookie |
$remote_addr и $proxy_add_x_forwarded_for$remote_addr — это IP...Up в выводе docker ps означает лишь одно: процесс внутри запущен. Приложение может зависнуть на инициализации, потерять соединение с базой данных или отвечать ошибками на каждый запрос — контейнер при этом остаётся «живым». Healthcheck решает эту проблему: Docker периодически выполняет команду проверки внутри контейнера и по её коду возврата определяет, действительно ли сервис работает.healthcheck объявляется внутри определения сервиса. Минимальный рабочий пример:services:
web:
image: nginx:latest
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:80"]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
test задаёт команду проверки. Два формата записи:["CMD", "curl", "-f", "http://localhost"] — команда выполняется напрямую без оболочки.["CMD-SHELL", "curl -f http://localhost || exit 1"] — команда передаётся в /bin/sh -c. Удобна, когда нужны пайпы, перенаправления или логические операторы.test установлен в ["NONE"], healthcheck отключается — это полезно, когда базовый образ содержит проверку, которая не подходит для вашего сценария.| Параметр | Значение по умолчанию | Что контролирует |
|---|---|---|
interval | 30s | Пауза между последовательными проверками |
timeout | 30s | Максимальное время ожидания ответа от команды проверки |
retries | 3 | Сколько подряд неудачных проверок нужно для перехода в статус unhealthy |
start_period | 0s | Окно после старта контейнера, в течение которого неудачные проверки не засчитываются |
start_interval | 5s | Интервал проверок внутри start_period (доступен в новых версиях Compose) |...docker ps такой контейнер отображается со статусом Restarting или быстро переключается между Up и Exited. Проблема не в самом Docker, а в том, что процесс внутри контейнера не может работать стабильно.docker ps показывает текущее состояние, но для диагностики нужен последний exit-код:docker ps -a --filter "name=mycontainer" --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
docker inspect:docker inspect --format='{{.State.ExitCode}} {{.State.OOMKilled}} {{.State.Error}}' mycontainer
| Код | Типичная причина |
|---|---|
| 0 | Процесс завершился штатно — контейнер не рассчитан на длительную работу |
| 1 | Ошибка приложения (исключение, неверная конфигурация) |
| 2 | Ошибка shell-скрипта или misuse команды |
| 126 | Файл найден, но не является исполняемым |
| 127 | Команда или бинарник не найдены |
| 137 | SIGKILL — чаще всего OOM-kill |
| 139 | SIGSEGV — segmentation fault |
| 143 | SIGTERM — graceful shutdown по таймауту |
## Последние 100 строк
docker logs --tail 100 mycontainer
## С временными метками
docker logs --timestamps mycontainer
## Непрерывное чтение (аналог tail -f)
docker logs --follow mycontainer
## Логи за последний час
docker logs --since 1h mycontainer
--follow покажет вывод каждого цикла. Обратите внимание на повторяющиеся сообщения об ошибках: они указывают на конкретную причину.sudo ufw status verbose
Status: inactive
ufw enable происходит сброс цепочек (flush), что может разорвать существующие соединения, включая текущую SSH-сессию. Поэтому правило для SSH добавляется до активации:sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 2222/tcp comment 'SSH'
sudo ufw enable
--force:sudo ufw --force enable
allow для SSH лучше использовать limit. UFW заблокирует IP-адрес, если с него инициировано 6 и более новых соединений за 30 секунд:sudo ufw limit 22/tcp comment 'SSH rate limit'
| Формат | Флаг | Восстановление | Сжатие | Параллельный дамп | Выборочный restore |
|---|---|---|---|---|---|
| Plain text | -Fp (по умолчанию) | psql | Нет (внешнее через gzip) | Нет | Нет |
| Custom | -Fc | pg_restore | Да (встроенное) | Нет | Да |
| Directory | -Fd | pg_restore | Да (gzip по умолчанию) | Да (-j) | Да |
| Tar | -Ft | pg_restore | Нет | Нет | Ограниченно |
-Fc): он сжат, позволяет выборочно восстанавливать объекты и работает с pg_restore. Directory format (-Fd) нужен, когда важна скорость дампа больших баз за счёт параллелизма.pg_dump -Fc -f mydb.dump mydb
-Fc задаёт custom-формат, -f указывает выходной файл, mydb — имя базы. Утилита подключается к локальному серверу с портом по умолчанию и именем пользователя, совпадающим с текущим системным.pg_dump -h db.example.com -p 5432 -U backup_user -Fc -f mydb.dump mydb
.zst
database.sql.zst
zstd database.sql
unzstd database.sql.zst
zstd -d database.sql.zst
скорость <-> степень сжатия
zstd -1 file
zstd -3 file
zstd -10 file
zstd -19 file
--ultra -20
--ultra -21
--ultra -22
.tar.zst
tar -cf - /var/www | zstd -T0 -3 -o backup.tar.zst
failed, systemd фиксирует причину и сохраняет её в журнале. Задача администратора — правильно прочитать эти данные. Ниже — последовательность действий от первого взгляда на статус до извлечения конкретной ошибки из логов.failed, когда его основной процесс завершается с ненулевым кодом, падает по сигналу, не успевает запуститься за отведённое время или нарушает условия, заданные в unit-файле. Это не отдельный тип ошибки, а обобщённое состояние, за которым всегда стоит конкретная причина, записанная в журнал.systemctl status <unit> выводит сводку о текущем (или последнем) запуске юнита. По умолчанию показываются 10 строк лога; для полного вывода используйте --lines и --full.systemctl status nginx.service --lines=50 --full
| Строка | Что показывает |
|---|---|
Loaded: | Путь к unit-файлу, состояние загрузки и enablement-статус |
Active: | Текущее состояние юнита |
Main PID: | PID основного процесса |
Status: | Текстовое сообщение от самого процесса (если сервис его отправляет) |
CGroup: | Дерево процессов юнита |
| Последние строки | Фрагмент журнала с последними записями |
failed сразу после редактирования конфига.