Http accept error

I found a post explaining the root problem in a lot more detail.
Nathan Smith even explains how to control timeouts on the TCP level, if needed.
Below is a summary of everything I could find on this particular problem, as well as the best practices to avoid this problem in future.

Problem

When a response is received regardless of whether response-body is required or not, the connection is kept alive until the response-body stream is closed. So, as mentioned in this thread, always close the response-body. Even if you do not need to use/read the body content:

func Ping(url string) (bool) {
    // simple GET request on given URL
    res, err := http.Get(url)
    if err != nil {
        // if unable to GET given URL, then ping must fail
        return false
    }

    // always close the response-body, even if content is not required
    defer res.Body.Close()

    // is the page status okay?
    return res.StatusCode == http.StatusOK
}

Best Practice

As mentioned by Nathan Smith never use the http.DefaultClient in production systems, this includes calls like http.Get as it uses http.DefaultClient at its base.

Another reason to avoid http.DefaultClient is that it is a Singleton (package level variable), meaning that the garbage collector will not try to clean it up, which will leave idling subsequent streams/sockets alive.

Instead create your own instance of http.Client and remember to always specify a sane Timeout:

func Ping(url string) (bool) {
    // create a new instance of http client struct, with a timeout of 2sec
    client := http.Client{ Timeout: time.Second * 2 }

    // simple GET request on given URL
    res, err := client.Get(url)
    if err != nil {
        // if unable to GET given URL, then ping must fail
        return false
    }

    // always close the response-body, even if content is not required
    defer res.Body.Close()

    // is the page status okay?
    return res.StatusCode == http.StatusOK
}

Safety Net

The safety net is for that newbie on the team, who does not know the shortfalls of http.DefaultClient usage. Or even that very useful, but not so active, open-source library that is still riddled with http.DefaultClient calls.

Since http.DefaultClient is a Singleton we can easily change the Timeout setting, just to ensure that legacy code does not cause idle connections to remain open.

I find it best to set this on the package main file in the init function:

package main

import (
    "net/http"
    "time"
)

func init() {
    /*
    Safety net for 'too many open files' issue on legacy code.
    Set a sane timeout duration for the http.DefaultClient, to ensure idle connections are terminated.
    Reference: https://stackoverflow.com/questions/37454236/net-http-server-too-many-open-files-error
    */
    http.DefaultClient.Timeout = time.Minute * 10
}

Очень часто при работе на высоконагруженных Linux серверах могут возникать ошибки “too many open files”. Это означает, что процесс открыл слишком много файлов (читай файловых дескрипторов) и не может открыть новые. В Linux ограничения “max open file limit“ установлены по умолчанию для каждого процесса и пользователя, и они не слишком высокие.

В данной статье мы рассмотрим, как проверить текущие ограничения на количество открытых файлов в Linux, как изменить этот параметр для всего сервера, для отдельных сервисов и для сеанса. Статья применима для большинства современных дистрибутивов Linux (Debian, Ubuntu, CentOS, RHEL, Oracle Linux, Rocky и т.д.)

Ошибка: Too many open files и лимиты на количество открытых файлов в Linux

Чаще всего ошибку “too many open files“. Чаще всего эта ошибка встречается на серверах с установленным веб-сервером NGINX/httpd, сервером БД (MySQL/MariaDB/PostgreSQL), при чтении большого количества логов. Например, когда веб-серверу Nginx не хватает лимита для открытия файлов, вы получите ошибку:

socket () failed (24: Too many open files) while connecting to upstream

Или:

HTTP: Accept error: accept tcp [::]:<port_number>: accept4: too many open files.

В Python:

OSError: [Errno 24] Too many open files.

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

# cat /proc/sys/fs/file-max

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

$ cat /proc/sys/fs/file-nr

7744    521      92233720

• 7744 — суммарное количество открытых файлов
• 521– число открытых файлов, но которые сейчас не используются
• 92233720– максимальное количество файлов, которое разрешено открывать

В Linux ограничение на максимальное количество открытых файлов можно натсроить на нескольких уровнях:

• Ядра ОС
• Сервиса
• Пользователя

Чтобы вывести текущее ограничение на количество открытых файлов в ядре Linux, выполните:

# sysctl fs.file-max

fs.file-max = 92233720

Выведем ограничение на количество открытых файлов для одного процесса текущего пользователя:

# ulimit -n

По умолчанию количество файлов для одного процесса этого ограничено числом 1024.

Выведем максимальное количество для одного пользователя (max user processes):

# ulimit –u

5041

Умножаем 1024 * 5041 дает нам 5161984 – это максимально количество открытых файлов всеми процессами пользователя.

В Linux есть два типа ограничений на количество открытых файлов: Hard и Soft. Soft ограничения носят рекомендательный характер, при превышении значения пользователь будет получать предупреждения. Если количество открытых файлов превысило hard лимит, пользователь не сможет открыть новые файлы пока не будет закрыты ранее открытые.

Для просмотра текущих лимитов используется команда ulimit с опцией
-S
(soft) или
-H
(hard) и параметром
-n
(the maximum number of open file descriptors).

Для вывода Soft-ограничения:

# ulimit -Sn

Для вывода Hard-ограничения:

# ulimit -Hn

Глобальные ограничения на количество открытых файлов в Linux

Чтобы разрешить всем сервисам открывать большее количество файлов, можно изменить лимиты на уровне всей ОС Linux. Чтобы новые настройки работали постоянно и не сбрасывались при перезапуске сервера или сессии, нужно поправить файл /etc/security/limits.conf. Строки с разрешениями выглядит так:

Имя_пользователя тип_огрничение название_ограничения значение

Например:

apache  hard nofile 978160
apache soft nofile 978160

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

* hard nofile 97816
* soft nofile 97816

Например, вы получили ошибку too many open files для nginx. Проверьте, сколько файлов разрешено открывать процессу этому пользователю:

$ sudo -u nginx bash -c 'ulimit -n'

1024

Для нагруженного сервера этого недостаточно. Добавьте в /etc/security/limits.conf строки

nginx hard nofile 50000
nginx soft nofile 50000

В старых ядрах Linux значение fs.file-max может быть равно 10000. Поэтому проверьте это значение и увеличьте его, чтобы оно было больше чем ограничение в limits.conf:

# sysctl -w fs.file-max=500000

fs.file-max = 500000

Проверьте, что в файле /etc/pam.d/common-session (Debian/Ubuntu или /etc/pam.d/login для CentOS/RedHat/Fedora) есть строчка:

session required pam_limits.so

Если нет, добавьте ее в конец. Она нужна, чтобы ограничения загружались при авторизации пользователя.

После изменений, перезапустите терминал и проверьте значение лимита max_open_files:

# ulimit -n


97816

Увеличить лимит открытых файловых дескрипторов для отдельного сервиса

Вы можете изменить лимит на количество открытых файловых дескрипторов для конкретного сервиса, а не для всей системы. Рассмотрим на примере apache. Чтобы изменить значения, откройте настройки службы через systemctl:

# systemctl edit httpd.service

Добавьте необходимые лимиты, например:

[Service]
LimitNOFILE=16000
LimitNOFILESoft=16000

После изменения, нужно обновить конфигурацию сервиса и перезапустить его:

# systemctl daemon-reload
# systemctl restart httpd.service

Чтобы проверить, изменились ли значения, нужно получить PID сервиса:

# systemctl status httpd.service

Например, вы определил PID сервиса 32724:

# cat /proc/32724/limits | grep "Max open files”

Значение должно быть 16000.

Так вы изменили значения Max open files для конкретного сервиса.

Увеличить количество открытых файлов для Nginx и Apache

После того, как вы увеличил ограничения на количество открытых файлов для сервера, нужно также поправить конфигурационный файл службы. Например, для веб-сервера Nginx в файле конфигурации /etc/nginx/nginx.conf нужно задать значение в директиве:

worker_rlimit_nofile 16000

Директива worker_rlimit_nofile задает ограничение на количество файлов, открытых в рабочем процессе (
RLIMIT_NOFILE
). В Nginx файловые дескрипторы нужны для возврата статического файла из кэша для каждого подключения клиента. Чем больше пользователей использует ваш сервер и чем больше статических файлов отдает nginx, тем большее количество дескрипторов используется. Сверху максимальное количество дескрипторов ограничивается на уровне ОС и/или сервиса. При превышении количеств открытых файлов nginx появится ошибка
socket() failed (24: Too many open files) while connecting to upstream
.

При настройке Nginx на высоконагруженном 8-ядерном сервере с worker_connections 8192 нужно в worker_rlimit_nofile указать 8192*2*8 (vCPU) = 131072.

После чего выполнить рестарт Nginx:

# nginx -t && service nginx -s reload

Для apache, нужно создать директорию:

# mkdir /lib/systemd/system/httpd.service.d/

После этого создайте файл limit_nofile.conf:

# nano /lib/systemd/system/httpd.service.d/limit_nofile.conf

И добавьте в него:

[Service]
LimitNOFILE=16000

Не забудьте перезапустить сервис httpd.

Лимиты file-max для текущей сессии

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

# ulimit -n 3000

Если указать здесь значение большее, чем заданное в hard limit, появится ошибка:

-bash: ulimit: open files: cannot modify limit: Operation not permitted

Когда вы завершите текущую сессию терминала и откроете новую, лимиты вернутся к начальным значениям, указанным в файле /etc/security/limits.conf.

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

Иногда возникают ошибки на стороне сервера и на стороне клиента, обычно их называют HTTP-ответами или кодами состояния. Одним из таких HTTP-ответов является ошибка «406 error» или «406 Not Acceptable».

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

В этой статье будут объяснены основные сведения об ошибке «406 Not Acceptable», ее причины, способы исправления и шаги по профилактике ее появления в будущем.

Что такое ошибка 406

Хорошая новость заключается в том, что сообщение об ошибке HTTP «406 Not Acceptable» встречается не так часто, как ошибка сервера 404 (которая обычно указывает на несуществующую веб-страницу) или даже ошибки 301 или 500 HTTP.

Чаще всего появляется во время редактирования постов, страниц, товаров, меток и других таксономий в WordPress. При этом отредактировать контент невозможно.

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

An appropriate representation of the requested resource /wp-admin/post.php could not be found on this server.

Сообщение обычно гласит (в переводе на русский):
Недопустимо

Соответствующее представление запрошенного ресурса /wp-admin/post.php не может быть найдено на этом сервере.

Иногда «запрошенный ресурс», в котором заключается проблема, определяется и выводится с другими сообщениями или информацией о сервере:

Внешний вид и текст сообщения об ошибке 406 зависит от веб-сайта, хоста и браузера, которые использовались для доступа к веб-сайту. Ошибка 406 может показать, где произошли ошибки. В других случаях отображается простая ошибка «406 Not Acceptable» без какой-либо информации о проблеме.
А теперь давайте представим, что браузеры говорят на простом английском, а не в этих загадочных сообщениях. В этом случае браузер скажет что-то вроде этого:

Здравствуйте, я браузер. Я попытался показать эту веб-страницу, но возникла одна из двух проблем:

1. Сервер веб-сайта отправил мне файл неправильного формата, поэтому я не могу его принять.
2. Сервер веб-сайта нарушает некоторые настройки или требования безопасности.

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

Если бы только браузеры были такими дружелюбными!

По сути, существует недопонимание между сервером и браузером или компьютером, используемым для представления веб-приложения. Браузер либо не может прочитать, что поступает, либо проверить данные, потому что они не соответствуют некоторым требованиям.

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

Смотрите также:

Наиболее распространенные ошибки SSL-соединения и методы их исправления

Что вызывает ошибку 406

Каждый раз, когда вы открываете веб-страницу, ваш браузер (например, Safari, Firefox, Brave, Chrome или Internet Explorer) отправляет запрос на сервер страницы для получения содержимого сайта и файлов базы данных. Браузер действует как посредник между вами и сервером – он сообщает серверу, что пользователь хочет видеть, и, надеюсь, верная информация возвращается.

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

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

Вот несколько примеров «плохих форматов» и «нарушений правил», которые могут возникать при запросах заголовков:

• Accept-ranges: на некоторых серверах установлены меры безопасности или разрешен только определенный диапазон размера файла в ответе. Если ответ пытается отправить слишком много байтов за пределы допустимого диапазона, вы увидите ошибку 406.
• Accept-encoding: это область заголовка, предназначенная для сжатия файлов, поэтому они быстро перемещаются с сервера в браузер. Некоторые методы и форматы сжатия не принимаются, что приводит к отображению кода ошибки 406.
• Accept-charset: относится к набору символов или к тому, как таблицы файлов сайта принимают код (например, CSS и HTML) и превращают его в понятные символы. В мире так много персонажей, языков и символов, что сложно охватить их все. Стандартная таблица называется ISO-8859, но есть и другие дополнительные таблицы. Время от времени выпускаются новые таблицы символов.
• Accept-language: обычно это другое имя для Accept-charset, которое ссылается на его ориентацию на международные языки.
• Нарушение типа MIME: иногда браузер запрашивает у сервера определенный тип MIME. Типы MIME – это элементы содержимого, такие как изображения JPEG, определенные видеоформаты или простой текст. Если сервер не может предоставить запрошенный тип MIME, например изображения JPEG, вы увидите ошибку 406.

Основной способ исправить ошибку 406 – проверить исходный код на наличие проблем в заголовках Accept-, Request- и Response- .

Самый простой способ просмотреть заголовки «Accept» и «Response» – открыть веб-страницу в браузере, щелкнуть правой кнопкой мыши и выбрать « Inspect» (Проверить).

Перейдите в Сеть> Заголовки, чтобы отобразить все запросы с этой веб-страницы.

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

Или можете обратиться к своему веб-разработчику. Однако проверка исходного кода намного проще, если есть инструменты для отладки и очистки базы данных, которые обсудим позже в этой статье.
Ошибка «406 Not Acceptable» сообщает, что клиент отправил действительный запрос на сервер, но запрос включал уникальное требование для сервера. Это специальное требование в первоначальном запросе было в форме HTTP Accept— заголовка.

Это оставляет нам несколько потенциальных причин:

1. Сервер не предоставил запрошенный тип MIME или правильные форматы, такие как видео в формате JPEG или mp4.
2. Сервер не вернулся с правильным языком (Accept-language). Например, он мог отправить ответ на немецком языке, когда браузер запросил французский.
3. Сервер использовал неправильный метод или формат сжатия в ответ на запрос Accept-encoding.
4. Сервер отправил обратно слишком много байтов, которые не совпадают с запросом Accept-ranges.
5. Серверу не удалось предоставить понятные символы, что привело бы к проблеме с запросом Accept-charset из браузера.

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

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

Как исправить ошибку 406

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

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

Убедитесь, что URL-адрес правильный

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

Ошибка 404 гораздо более вероятна, чем ошибка 406 в этой ситуации. Но если URL-адрес веб-сайта действителен, то можно увидеть и ошибку «406 Not Acceptable». Тем не менее, есть что-то странное в том, как браузер переводит запрос. Например, добавление «JSON» или «PHP» в конец URL-адресов может быть неверно истолковано как запрос для этих конкретных форматов, даже если клиенту они не нужны.

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

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

Сбросьте свои устройства и сети

Другая проблема на стороне клиента иногда связана с теми же заголовками Accept, отправленными с компьютера пользователя на платформу, которая не может удовлетворить запрос. Многие из этих платформ включают игровые или медиа-ориентированные системы, такие как Hulu, или музыкальные торговые площадки, такие как Spotify.

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

Хотя это может произойти с любой платформой, некоторые платформы, которые обычно сообщают об ошибках 406:

• Hulu
• Гугл игры
• Игры Square Enix
• Netflix
• Xbox
• Windows (обычно для игр)

Этот список далеко не полный, но он дает представление о том, где может возникнуть ошибка 406.

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

Хотя трудно помочь вам устранить неполадки для каждой конкретной платформы, рассмотрите следующие рекомендации и проверьте, устранена ли ошибка:

• Войдите в Интернет, чтобы проверить статус сервера платформы. Это может быть просто проблема с сервером компании.
• Перезагрузите компьютер, игровую систему, потоковое устройство или другие машины.
• Отсоедините все устройства от кабелей, подождите несколько минут, прежде чем снова их все подключить, и проверьте, исчезла ли ошибка.
• Убедитесь, что в приложении установлена ​самая последняя версия. Также проверьте, доступны ли обновления прошивки для какой-либо из ваших машин.
• Сбросьте настройки домашней или офисной сети (Wi-Fi или подключение к Интернету через маршрутизатор).
• Если проблема не исчезнет, ​​подумайте о переключении с беспроводной сети на проводное сетевое соединение.
• Хотя это не всегда возможно, рассмотрите возможность дублирования ошибки на совершенно другом компьютере. Убедитесь, что устройство находится в той же сети. Если вы не можете воспроизвести ошибку, проверьте свою сеть и исходный компьютер.

Если все это не помогло, перейдите в свою поисковую систему и введите название своей платформы вместе с «кодом ошибки + 406», чтобы получить рекомендации по устранению неполадок для конкретной платформы. Этот запрос часто открывает форумы и вспомогательную документацию, которая поможет определиться.

Откат последних изменений в CMS

Пришло время изучить систему, используемую для ваших веб-сайтов или приложений. Может случится так, что система управления контентом, такая как WordPress, является прямой причиной ошибки «406 Not Acceptable» из-за сложностей внутри файлов сайта.

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

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

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

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

Для всех систем, не относящихся к WordPress, выполните поиск по запросу «название платформы + как перейти на более раннюю версию».

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

Удалите и переустановите плагины, темы и расширения

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

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

Важно!

Начните с плагинов, если ничего не найдете – перейдите к теме.

Анализируйте состояние БД на предмет изменений и конфликтов

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

Если плагин или тема не были причиной ошибки, следует проверить базу данных: является ли основным источником ошибки. Иногда изменение базы данных, случайное или целенаправленное, становится основной причиной появления ошибки 406.

Чтобы просканировать и исправить БД, рассмотрите следующие решения:

1. Установите сканер и очиститель базы данных, который удаляет бесполезные и проблемные таблицы и активы. Некоторые параметры включены в плагины WP Optimize и Advanced Database Cleaner. Большая часть этого процесса включает в себя удаление старых или потерянных элементов, таких как мусорные записи, исправления и метаданные. Это надежный первый шаг к очистке БД и потенциальному устранению ошибки 406.
2. Просканируйте базу данных и найдите записи и таблицы, которые могут быть изменены проблемным плагином или выглядят неуместными или ненужными.
3. Если у вас есть представление о том, что не так с базой данных, перейдите в поисковую систему и обратитесь за помощью на форумы и в другие обсуждения в Интернете. Есть большая вероятность, что кто-то другой столкнулся с той же проблемой.

Анализируйте журналы вашего сервера

Предыдущие рекомендации сосредоточены на устранении неполадок на стороне клиента и CMS. Теперь рассмотрим проблемы на стороне сервера. Этот и следующие советы лучше всего подходят, если вы не используете CMS или знаете, что ошибка 406 не связана с CMS или клиентским компьютером.

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

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

Отладка веб-приложения (например, WordPress)

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

Один из лучших способов запустить полное сканирование WordPress (или любого веб-приложения) – отладить файлы базы данных и веб-сайта. К счастью, отладка не означает, что вам нужно читать каждую строчку кода и самостоятельно выявлять ошибки. Для этой конкретной цели доступны программы, и многие хостинги предоставляют их на панели управления сайтами.

Предотвращение ошибки 406 в будущем

Проблема с ошибкой 406 заключается в том, что она может появляться в различных ситуациях. Можно увидеть ошибку «406 Not Acceptable HTTP» при просмотре Hulu или Netflix в качестве обычного пользователя.

Это не очень приятно, но все можно исправить с помощью небольшого устранения неполадок. Более опасно появление ошибки 406, когда она происходит на вашем веб-сайте или в приложении. В таких случаях необходимо проверить файлы сервера и сайта CMS.

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

• Устанавливайте только необходимые и проверенные плагины, темы и расширения. Всегда сводите эти элементы к минимуму.
• Никогда не изменяйте основные файлы WordPress, если вы в этом не уверены и не знаете, что делаете.
• Запускайте регулярно очистители/оптимизаторы базы данных и сайта. Рекомендуем выполнять этот процесс каждый месяц, а в идеале найти чистый плагин, который автоматически запускается в фоновом режиме.
• Возьмите за привычку отлаживать сервер и веб-приложение. Многие ресурсы имеют такую ​функциональность.
• Установите автоматическое резервное копирование сайта или приложения. Таким образом, конфликт кода или ошибка не вызовут у вас особого стресса, поскольку можно восстановить предыдущую версию веб-сайта и начать с нее.
• Выполните ручное резервное копирование сайта, прежде чем планировать обновление WordPress и любых плагинов, даже если уже запущено автоматическое резервное копирование (лучше перестраховаться, чем сожалеть). Также разумно выполнить резервное копирование перед редактированием любых файлов или добавлением нового кода на сайт.

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

Источник: kinsta.com

Изучает сайтостроение с 2008 года. Практикующий вебмастер, специализирующий на создание сайтов на WordPress. Задать вопрос Алексею можно на https://profiles.wordpress.org/wpthemeus/