Редиректы nginx. примеры перенаправлений в nginx

1. Установка Nginx

В официальных репозиториях CentOS есть Nginx и он, скорее всего, уже установлен в вашей системе. Но мы хотим чтобы сайт работал по протоколу http2, который позволяет передавать все данные одним подключением, а это увеличивает производительность. Для работы по http2 вам понадобиться настроить SSL сертификат, но об этом уже написано в статье получение сертификата Lets Encrypt Nginx. Но это еще не все. для переключения с обычного SSL на HTTP2.0 в большинстве браузеров сейчас используется протокол ALPN, а он поддерживается начиная с OpenSSL 1.02. В то время, как в репозиториях есть только OpenSSL 1.01. Поэтому нам нужно установить версию Nginx, собранную с OpenSSL 1.02. Для этого можно использовать Broken Repo:

Если вы используете репозиторий EPEL, то нужно указать что не надо из него брать Nginx:

Теперь для установки правильной версии Nginx достаточно набрать:

Будет установлена самая последняя версия Nginx 1.13.2, с полной поддержкой ALPN. Дальше перейдем к настройке.

Настройка журнала ошибок

Nginx записывает сообщения об ошибках приложения и общих серверах в файл журнала ошибок. Если вы столкнулись с ошибками в вашем веб-приложении, журнал ошибок – это первое место, с которого можно начать устранение неполадок.

Директива error_log включает и устанавливает место и уровень серьезности журнала ошибок. Он принимает следующую форму и может быть установлен в пределах http, server или блока location:

error_log log_file log_level

Параметр log_level устанавливает уровень протоколирования. Ниже перечислены уровни их серьезности (от низкого до высокого):

debug – отладка сообщений.
info – информационные сообщения.
notice – Уведомления.
warn – Предупреждения.
error – Ошибки при обработке запроса.
crit – Критические вопросы. Требует быстрых действий.
alert – Оповещения. Действие должно быть принято немедленно.
emerg – Чрезвычайная ситуация. Система находится в нерабочем состоянии.

Каждый уровень журнала включает в себя более высокие уровни. Например, если вы установите уровень журнала как warn, Nginx будет также регистрировать сообщения error, crit, alert и emerg.

Если параметр log_level не указан, по умолчанию используется значение error.

По умолчанию директива error_log определена в директиве http внутри основного файла nginx.conf:
/etc/nginx/nginx.conf

http {
  ...
  error_log  /var/log/nginx/error.log;
  ...
}

Как и в случае с журналами доступа, рекомендуется устанавливать отдельный файл журнала ошибок для каждого блока сервера, который переопределяет параметр, унаследованный от более высоких уровней.

Например, чтобы установить журнал ошибок domain.ru для warn, используйте:

http {
  ...
  error_log  /var/log/nginx/error.log;
  ...

  server {
    server_name domain.ru
    error_log  /var/log/nginx/domain.error.log warn;
    ...
  }
}

Всякий раз, когда вы изменяете файл конфигурации, вы должны перезапустить службу Nginx, чтобы изменения вступили в силу.

Чтение и понимание файлов журнала Nginx

Вы можете открывать и анализировать лог – файлы, используя стандартные команды, такие как cat, less, grep, cut, awk, и так далее.

Вот пример записи из файла журнала доступа, который использует формат журнала объединения Nginx по умолчанию:

192.168.33.1 - - [15/Oct/2019:19:41:46 +0000] "GET / HTTP/1.1" 200 396 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36"

Давайте разберемся, что означает каждое поле записи:

$remote_addr- 192.168.33.1 – IP-адрес клиента, сделавшего запрос.
$remote_user- — HTTP. Аутентифицированный пользователь HTTP. Если имя пользователя не задано, это поле отображается .
[15/Oct/2019:19:41:46 +0000] – Время локального сервера.
“$request”- “GET / HTTP/1.1” – Тип запроса, путь и протокол.
$status- 200 – Код ответа сервера.
$body_bytes_sent- 396 – Размер ответа сервера в байтах.
“$http_referer”- “-” – URL реферала.
“$http_user_agent” – Mozilla/5.0 …- Пользовательский агент клиента (веб-браузер).

Используйте команду tail для просмотра файла журнала в режиме реального времени:

tail -f  access.log

Автоиндекс

Альтернативным решением является разрешение индекса директории. Индекс директории означает, что если индексный файл не найден, сервер отобразит все содержимое директории.

По соображениям безопасности индекс директории в NGINX по умолчанию отключен.

При «403 forbidden NGINX», если вы хотите показать индекс директории в ситуациях, когда NGINX не может найти (идентифицировать) файл, отредактируйте nginx.conf, как описано выше, и добавьте в него две следующие директивы:

Autoindex on;
Autoindex_exact_size off;

Эти директивы должны быть добавлены в блок location. Можно либо добавить их в существующий блок location/, либо добавить новый. Окончательный результат должен выглядеть так:

location / {
  
  autoindex on;
  autoindex_exact_size off;
  }

Также можно активировать индексирование директории в определенной папке, если не хотите, чтобы она была доступна для всего сайта:

location /myfiles {
  autoindex on;
  autoindex_exact_size off;
  }

Сохраните изменения в файле, затем перезапустите NGINX командой:

sudo nginx -s reload

Почему возникает ошибка 404 в Nginx

Давайте сначала разберёмся, как обрабатываются URL в Nginx. Когда веб-сервер определил, к какому блоку server (сайту) нужно передать запрос пользователя, просматриваются все префиксные блоки location и выбирается тот, который подходит лучше всего. Например, рассмотрим стандартную конфигурацию для WordPress. Здесь префиксные location отмечены зелёным, а с регулярным выражением — оранжевым:

location / {index index.html index.php;}location /favicon.ico {access_log off;}location ~* \.(gif|jpg|png)$ {expires 30d;}location ~ \.php$ {fastcgi_pass localhost:9000;fastcgi_param SCRIPT_FILENAME$document_root$fastcgi_script_name;include fastcgi_params;}

Префиксные локейшены всегда начинаются с символа /. Регулярные же содержат символы регулярных выражений: ~ $ ^ * и так далее. Если пользователь запрашивает favicon.ico, то будет выбран второй location, так как он лучше всего соответствует запросу, при любом другом запросе будет выбран location /, так как он соответствует всем запросам, а других префиксных location у нас нет. Это просто, а дальше начинается магия. После того, как был найден нужный location, Nginx начинает проверять все регулярные выражения в порядке их следования в конфигурационном файле.

При первом же совпадении Nginx останавливает поиск и передаёт управление этому location. Или, если совпадений не было найдено, используется ранее обнаруженный префиксный location. Например, если запрос заканчивается на .php, то первый location будет проигнорирован, а управление передастся четвёртому (~ \.php$)

Таким образом, любое неверно составленное регулярное выражение в любой части конфигурационного файла может полностью всё сломать. Поэтому разработчики рекомендуют по минимум использовать регулярные выражения. Что касается вложенных location, то обрабатываются они так же как и основные, только уже после передачи управления в нужный location. Путём чтения конфигурационного файла понять, какой location вызывает 404 сложно, поэтому, чтобы исправить ошибку, нам понадобиться режим отладки Nginx.

4. Настройка PageSpeed

Google Pagespeed — это модуль Nginx, который выполняет различные оптимизации для того, чтобы страницы грузились быстрее, веб-сервер работал эффективнее, а пользователи не чувствовали дискомфорта. Сюда входит кэширование, оптимизация html кода, оптимизация картинок, объединение javascript и css кода и многое другое. Все это выполняется на уровне Nginx, поэтому эффективнее, чем если бы вы это делали в php. Но тут есть один недостаток, модуль удаляет заголовок Last Modified.

Дело в том, что PageSpeed устанавливает очень долгий строк кэширования для всех файлов, а в имя файла добавляет его хэш. Так скорость загрузки ресурсов выходит намного выше, поскольку браузер будет запрашивать файлы только с новым хэшем, а LastModified удаляется чтобы пользователи смогли увидеть изменения в случае если какой-либо файл будет изменен. А теперь рассмотрим как установить модуль. Нам придется собрать его из исходных кодов.

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

Скачайте и распакуйте исходники Nginx для вашей версии, например, 1.13.3:

Настройка сервера nginx не включает пере сборку и замену программы из репозитория, мы просто используем эти исходники для сборки модуля. Скачайте и распакуйте исходники PageSpeed:

Скачайте и распакуйте библиотеку оптимизации PageSpeed в папку с исходниками модуля:

Скачайте и распакуйте исходники OpenSSL 1.02:

Теперь нам нужно собрать модуль. Сначала смотрим опции, с которыми собран текущий Nginx:

А теперь переходим в папку с Nginx, подставляем все полученные опции, опцию —add-dynamic-module для PageSpeed, OpenSSL и пробуем собрать:

Если все было сделано правильно, то на выходе вы получите модуль ngx_pagespeed.so в папке obj, его нужно скопировать в папку /etc/nginx/modules:

Создаем папку для кэша:

Теперь добавьте такую строчку для включения модуля в /etc/nginx/nginx.conf:

Затем, в секцию сервер достаточно добавить:

Теперь вам достаточно перезапустить nginx чтобы изменения вступили в силу:

Обращайте внимание на подсказки, которые дает вам интуиция.

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

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

И я поняла, почему этот первый шаг обычно оказывается самым сложным – потому что сознательное отрицание наличия проблемы встает непреодолимой стеной на пути к ее решению.

С HTTP на HTTPS (другой порт)

Пример конфигурации для перенаправления запросов на другой порт — с 80 (http) на 443 (https):

server {
listen 80;
server_name domain.ru www.domain.ru;
return 301 https://$host$request_uri;
}

* в данном примере для всех обращений к сайту domain.ru по 80 порту (http) будет работать редирект на 443 порт (https) с кодом 301 (для склеивания доменов).

Также мы можем добавить условие, чтобы не перенаправлять на https для определенных ссылок, например:

server {
listen 80;
server_name domain.ru www.domain.ru;
if ($uri !~ /page.html){
return 301 https://$host$request_uri;
}
}

* в данном примере запрос на страницу /page.html будет открыт по http.

Настройка журнала ошибок

Nginx записывает сообщения об ошибках приложения и общих ошибках сервера в файл журнала ошибок. Если вы испытываете ошибки в своем веб-приложении, журнал ошибок — это первое место, с которого можно начать поиск и устранение неисправностей.

Директива включает и устанавливает расположение и уровень серьезности журнала ошибок. Он имеет следующую форму и может быть установлен в блоке , или :

Параметр устанавливает уровень ведения журнала. Ниже перечислены уровни в порядке их серьезности (от низкого до высокого):

— сообщения.
— Информационные сообщения.
— Уведомления.
— Предупреждения.
— Ошибки при обработке запроса.
— Критические проблемы. Требуется быстрое действие.
— Оповещения. Действия должны быть предприняты немедленно.
— Чрезвычайная ситуация. Система находится в непригодном для использования состоянии.

Каждый уровень журнала включает в себя более высокие уровни. Например, если вы установите уровень журнала , чтобы , Nginx будет также регистрировать , , и сообщения.

Если параметр не указан, по умолчанию используется .

По умолчанию директива определена в директиве внутри основного файла nginx.conf:

/etc/nginx/nginx.conf

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

Например, чтобы настроить журнал ошибок domain.com на вы должны использовать:

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

Перенаправление запросов для отсутствующих доменов (перенаправление по умолчанию)

Если обращение к веб-серверу идет по IP-адресу или домену, который не прописан в конфигурационном файле, можно перенаправить весь трафик на домен по умолчанию:

server {
listen 80 default_server;
return 302 https://welcome.domain.ru$request_uri;
}

или независимо от протокола:

server {
listen 80 default_server;
return 302 $scheme://welcome.domain.ru$request_uri;
}
server {
listen 443 ssl default_server;
return 302 $scheme://welcome.domain.ru$request_uri;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;
}

* $scheme позволяет перевести запрос на тот же протокол (http или https), по которому он был инициирован.
* если nginx должен слушать и обрабатывать запросы по https, необходимо указывать в настройках пути к сертификатам.

Примите решение избавиться от хлама в вашей жизни и действуйте, не оглядываясь назад.

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

Запомните раз и навсегда – люди и вещи редко держатся за нас, чаще всего это мы держимся за них. Каким бы хорошим и добрым ни был этот человек, это было давно, и раз уж вы приняли решение отправиться разными дорогами, претворите его в жизнь – как бы больно и неприятно вам ни было расставаться с привычным.

Признайте и подтвердите значимость того, что вам говорят.

Порою простой кивок головы может стать для любимого человека сильным и позитивным сигналом вашей поддержки. То же самое относится и ко вовремя сказанному «Угу»

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

А еще они показывают, что, по крайней мере, в данный момент вы ставите его чувства выше ваших, и не собираетесь его перебивать, чтобы поделиться своим мнением, каким бы оно ни было. Кроме того, эти выражения замечаются вашим собеседником в «фоновом» режиме, и не прерывают его поток мыслей.

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

Что означает ошибка 404 в Nginx

По сути, » ошибка 404 ″ означает, что ваш веб-браузер или веб-браузер вашего посетителя был успешно подключен к серверу веб-сайта или хосту. Однако ему не удалось найти запрошенный ресурс, например имя файла или какой-либо конкретный URL-адрес.

Например, если кто-то попытается перейти на » yourwebsite.com/anypostname » и не имеет никакого контента, связанного с » anypostname «, в таком случае вы получите ошибку 404 в своем браузере, поскольку запрошенный ресурс не существует. Другими словами, мы можем сказать, что когда запрашиваемый ресурс, такой как файл JavaScript, изображение или CSS, отсутствует, ваш работающий браузер выдаст ошибку „404“.

3 ответа

Лучший ответ

Хорошо, некоторые части этих ответов были полезны для поиска полного решения, особенно из @ Мэтта. Однако мне потребовалось довольно много времени, чтобы заставить это работать, поэтому я решил написать свой собственный ответ со всеми необходимыми деталями, с которыми другие могут также бороться.

Первым делом нужно создать сервер изображений Docker, способный отвечать на любой запрос с содержимым 404, кроме и . Как @ Мэтт упомянул, что это может быть экземпляр Nginx (который я использовал). Подводить итоги:

должен вернуть
является необязательным, но он должен возвращать данные, которые могут быть прочитаны Прометеем, если вы используете их для метрик k8s. Nginx может предоставить некоторые основные данные, которые Prometheus может прочитать. Рассмотрите эту ссылку, если вы хотите получить полную интеграцию Prometheus с Nginx .
возвращает 404 с вашим пользовательским содержимым HTML.

Таким образом, выглядит так:

В той же папке, где находится Dockerfile, создайте этот файл конфигурации Nginx:

Наконец, предоставьте файл с HTML / CSS на свой вкус.

Теперь создайте образ Docker с помощью:

Пометьте это изображение так, чтобы оно было готово для отправки в DockerHub (или в ваш собственный личный реестр Docker):

Вставьте изображение в репозиторий DockerHub:

Теперь пришло время интегрировать этот собственный пользовательский образ по умолчанию в установку Helm. Для этого нам сначала нужно создать этот файл ресурсов k8s ():

Предполагая, что у нас уже есть пространство имен k8s , мы можем создать эти два ресурса.

Теперь, чтобы связать Nginx Ingress Controller с нашей новой службой, мы могли бы просто отредактировать развертывание Ingress Controller. Но я решил полностью удалить его через Хелм:

И установите его снова с помощью этой команды (убедитесь, что у вас есть флаг с соответствующими аргументами):

С этими шагами вы должны получить работающую пользовательскую базовую реализацию по умолчанию. Здесь — репозиторий GitHub с файлами, которые я использовал в этом ответе.

dvdblk
4 Мар 2020 в 20:10

В проекте предусмотрено специальное приложение «Перейти к ошибке» который может быть встроен в образ контейнера для замены .

В конце концов, это веб-сервер, который отвечает на любой запрос с контентом 404, кроме и . Вы можете сделать это с помощью экземпляра nginx и страниц с ошибками HTML, если хотите.

Вы, вероятно, не хотите использовать полную пользовательскую обработку ошибок это немного отличается, когда входной контроллер будет искать определенные коды состояния HTTP из обычного бэкэнда приложения и передавать их в бэкэнд по умолчанию для обработки. Это вызывает проблемы для большинства приложений, если они не были предназначены для использования с самого начала.

Matt
15 Фев 2020 в 00:51

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

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

Arghya Sadhu
15 Фев 2020 в 05:32

Настройка журнала доступа

Каждый раз, когда клиентский запрос обрабатывается, Nginx генерирует новое событие в журнале доступа. Каждая запись события содержит отметку времени и включает различную информацию о клиенте и запрошенном ресурсе. Журналы доступа могут показать вам местоположение посетителей, страницу, которую они посещают, сколько времени они проводят на странице и многое другое.

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

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

Где — это полный путь к файлу журнала, а — формат, используемый файлом журнала.

Журнал доступа можно включить в блоке , или .

По умолчанию журнал доступа глобально включен в директиве в основном файле конфигурации Nginx.

/etc/nginx/nginx.conf

Для удобства чтения рекомендуется создавать отдельный файл журнала доступа для каждого серверного блока. Директива установленная в директиве директиву, установленную в директиве (более высокого уровня).

/etc/nginx/conf.d/domain.com.conf

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

Чтобы изменить формат ведения журнала, отмените настройку по умолчанию или определите новую. Например, чтобы определить новый формат ведения журнала с именем custom, который расширит комбинированный формат значением, показывающим заголовок добавьте следующее определение в директиву или :

Чтобы использовать новый формат, укажите его имя после файла журнала, как показано ниже:

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

Настройка перенаправлений

Настройки необходимо вносить в файлах конфигураций виртуальных доменов. В Linux на основе RPM (CentOS, Red Hat), как правило, они расположены в директории /etc/nginx/conf.d/. В Linux на основе Deb (Ubuntu, Debian) — в директории /etc/nginx/sites-enabled/. Во FreeBSD все в одном файле — /usr/local/etc/nginx/nginx.conf.

Саму настройку на перенаправление в NGINX можно прописать несколькими способами.

1. Первый:

rewrite ^ https://$host$request_uri? <флаг>;

* $host — имя хоста из запроса, если отсутствует — имя в поле «Host» заголовка, если тоже отсутствует — имя сервера; $request_uri — первоначальный запрос с аргументами (все, что идет после доменного имени).
** где флаги могут быть следующие:

permanent — перенаправление с кодом 301.
redirect — перенаправить с кодом 302.
last — закончить обработку с переходом в новый location.
break — закончить обработку и остаться в текущем location.

2. Второй:

return <код> https://$host$request_uri;

* где коды могут использоваться любые, но чаще всего — 301, 302, 404.

Есть различные мнения, какой из методов лучше и безопаснее, поэтому каким воспользоваться — решать по ситуации. В данных примерах используются оба варианта.

После внесения изменений, необходимо проверить их корректность:

nginx -t

И для их применения перезапустить веб-сервер:

systemctl restart nginx

service nginx restart

* в первом примере перезапуск выполняется на новых системах Linux. Второй пример — на устаревших или FreeBSD.

Проверяя редиректы в браузере, следует учесть, что настройки могут кэшироваться. Для обновления кэша используйте комбинацию Ctrl + F5. Если и это не помогает, закрывайте вкладку и открывайте новую.

Сделайте глубокий вдох.

Обращайте внимание на то, как вы дышите во время общения с этим любимым человеком. Не задерживаете ли вы его в предвкушении момента, когда будет ваша очередь говорить? Если, когда дело доходит до ответа, у вас не хватает воздуха в легких, это может изменить тон вашего ответа, а следовательно, и восприятие собеседником

Весьма возможно, что ваша реплика прозвучит более жестко или нетерпеливо, чем вы хотели.

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

Как исправить ошибку 404 Nginx с помощью онлайн-инструментов

» Ошибка 404 Nginx » также связана с внешними ресурсами и возникает, когда эти ресурсы удаляются или изменяются

Вот почему так важно часто выполнять проверку ошибок 404, чтобы убедиться, что ссылки на ваш веб-сайт не повреждены. Регулярная проверка и исправление неработающих ссылок поможет вам убедиться, что пользовательский опыт посетителя вашего веб-сайта находится на стабильном уровне

Ниже приведены некоторые инструменты, которые можно использовать для проверки ошибок «404 Not Found»:

W3C Проверить ссылку

В онлайн-инструменте W3C Link Checker вы должны ввести URL-адрес своего веб-сайта, и он просканирует все ваши веб-страницы на предмет 404 Not Found и других проблем. Когда сканирование закончится, оно вернет все неработающие URL-адреса вместе с другими результатами:

Check My Links

Check My Links — это базовый плагин Chrome, который позволяет вам проверять ссылки на текущей веб-странице. Когда этот плагин активирован, расширение определит, действительны ли ссылки на текущей странице или нет:

Broken Link Checker

Broken Link Checker — еще один полезный плагин, который предлагает различные методы проверки неработающих ссылок на вашем сайте. Можно установить период времени, при котором этот плагин будет проверять неработающие ссылки каждые «X» часов. Вы можете выбрать, должен ли плагин отправлять по электронной почте отчет, содержащий все неработающие ссылки или часть сайта, которая успешно просканирована:

Если вы столкнулись с ошибкой Nginx «404 Not Found» или хотите убедиться, что ссылки на ваш сайт не сломаны, или отслеживать ваш сайт, используйте вышеуказанные методы, чтобы исправить это.

Видеть – значит верить

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

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

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

Перевод статьи You Can’t Change or Fix People, So Listen Instead via Клубер