diff --git a/docs/ru/docs/deployment/concepts.md b/docs/ru/docs/deployment/concepts.md
index 23c62b8d3..86dbdabe5 100644
--- a/docs/ru/docs/deployment/concepts.md
+++ b/docs/ru/docs/deployment/concepts.md
@@ -27,13 +27,13 @@
 
 В [предыдущей главе про HTTPS](https.md) мы разобрались, как HTTPS обеспечивает шифрование для вашего API.
 
-Также мы увидели, что HTTPS обычно обеспечивает компонент, **внешний** по отношению к серверу вашего приложения — **прокси-сервер TSL-терминации**.
+Также мы увидели, что HTTPS обычно обеспечивает компонент, **внешний** по отношению к серверу вашего приложения — **прокси-сервер TLS-терминации**.
 
 И должен быть компонент, отвечающий за **обновление HTTPS‑сертификатов** — это может быть тот же самый компонент или отдельный.
 
 ### Примеры инструментов для HTTPS { #example-tools-for-https }
 
-Некоторые инструменты, которые можно использовать как прокси-сервер TSL-терминации:
+Некоторые инструменты, которые можно использовать как прокси-сервер TLS-терминации:
 
 * Traefik
     * Автоматически обновляет сертификаты ✨
@@ -47,7 +47,7 @@
     * С внешним компонентом (например, cert-manager) для обновления сертификатов
 * Обрабатывается внутри облачного провайдера как часть его услуг (см. ниже 👇)
 
-Другой вариант — использовать **облачный сервис**, который возьмёт на себя больше задач, включая настройку HTTPS. Там могут быть ограничения или дополнительная стоимость и т.п., но в таком случае вам не придётся самим настраивать прокси-сервер TSL-терминации.
+Другой вариант — использовать **облачный сервис**, который возьмёт на себя больше задач, включая настройку HTTPS. Там могут быть ограничения или дополнительная стоимость и т.п., но в таком случае вам не придётся самим настраивать прокси-сервер TLS-терминации.
 
 В следующих главах я покажу конкретные примеры.
 
diff --git a/docs/ru/docs/deployment/docker.md b/docs/ru/docs/deployment/docker.md
index c3cf9a328..1a7586f53 100644
--- a/docs/ru/docs/deployment/docker.md
+++ b/docs/ru/docs/deployment/docker.md
@@ -273,9 +273,9 @@ CMD fastapi run app/main.py --port 80
 └── requirements.txt
 ```
 
-#### За прокси-сервером TSL-терминации { #behind-a-tls-termination-proxy }
+#### За прокси-сервером TLS-терминации { #behind-a-tls-termination-proxy }
 
-Если вы запускаете контейнер за прокси-сервером TSL-терминации (балансировщиком нагрузки), таким как Nginx или Traefik, добавьте опцию `--proxy-headers`. Это сообщит Uvicorn (через FastAPI CLI), что можно доверять заголовкам, отправленным этим прокси и сообщающим, что приложение работает за HTTPS, и т.д.
+Если вы запускаете контейнер за прокси-сервером TLS-терминации (балансировщиком нагрузки), таким как Nginx или Traefik, добавьте опцию `--proxy-headers`. Это сообщит Uvicorn (через FastAPI CLI), что можно доверять заголовкам, отправленным этим прокси и сообщающим, что приложение работает за HTTPS, и т.д.
 
 ```Dockerfile
 CMD ["fastapi", "run", "app/main.py", "--proxy-headers", "--port", "80"]
@@ -462,17 +462,17 @@ CMD ["fastapi", "run", "main.py", "--port", "80"]
 
 ### Балансировщик нагрузки { #load-balancer }
 
-При использовании контейнеров обычно есть компонент, **слушающий главный порт**. Это может быть другой контейнер — **прокси-сервер TSL-терминации** для обработки **HTTPS** или похожий инструмент.
+При использовании контейнеров обычно есть компонент, **слушающий главный порт**. Это может быть другой контейнер — **прокси-сервер TLS-терминации** для обработки **HTTPS** или похожий инструмент.
 
 Поскольку этот компонент принимает **нагрузку** запросов и распределяет её между воркерами **сбалансированно**, его часто называют **балансировщиком нагрузки**.
 
 /// tip | Подсказка
 
-Тот же компонент **прокси-сервер TSL-терминации**, который обрабатывает HTTPS, скорее всего также будет **балансировщиком нагрузки**.
+Тот же компонент **прокси-сервер TLS-терминации**, который обрабатывает HTTPS, скорее всего также будет **балансировщиком нагрузки**.
 
 ///
 
-При работе с контейнерами система, которую вы используете для запуска и управления ими, уже имеет внутренние средства для передачи **сетевого взаимодействия** (например, HTTP-запросов) от **балансировщика нагрузки** (который также может быть **прокси-сервером TSL-терминации**) к контейнеру(-ам) с вашим приложением.
+При работе с контейнерами система, которую вы используете для запуска и управления ими, уже имеет внутренние средства для передачи **сетевого взаимодействия** (например, HTTP-запросов) от **балансировщика нагрузки** (который также может быть **прокси-сервером TLS-терминации**) к контейнеру(-ам) с вашим приложением.
 
 ### Один балансировщик — несколько контейнеров-воркеров { #one-load-balancer-multiple-worker-containers }