500 server error pterodactyl

# Troubleshooting

# Reading Error Logs

If you ever encounter an unexpected error with the Panel the first thing you will likely be asked for is the logs. To retrieve these, simply execute the command below which will output the last 100 lines of the Panel’s log file.

# Parsing the Error

When you run the command above, you’ll probably be hit with a huge wall of text that might scare you. Fear not, this is simply a stacktrace leading to the cause of the error, and you can actually ignore almost all of it when looking for the cause of the error. Lets take a look at some example output below, which has been truncated to make this easier to follow with.

The first thing you’ll want to do is follow the chain of numbers up until you find #0 , this will be the function that triggered the exception. Right above line 0 you will see a line that has the date and time in brackets, [2018-07-19 00:50:24] above for example. This line will be the human readable exception that you can use to understand what went wrong.

# Understanding the Error

In the example above we can see that the actual error was:

From this error we can determine that there was an error performing a file_put_contents()

(opens new window) call, and the error was that we couldn’t open the file because permissions were denied. Its okay if you don’t understand the error at all, but it does help you get faster support if you’re able to provide these logs, and at least find the source of the error. Sometimes the errors are pretty straightforward and will tell you exactly what went wrong, such as a ConnectionException being thrown when the Panel can’t connect to the Daemon.

# Utilizing GREP

If you’re trying to go through a bunch of errors quickly, you can use the command below which will limit the results returned to only be the actual error lines, without all of the stack traces.

# Transfer Exceptions / XHR Poll Error

If you are seeing errors similar to the examples below, chances are there is some networking related issue, or you just don’t have a required service running.

# Example Errors

«We were unable to connect to the main Socket.IO server, there may be network issues currently. The panel may not work as expected.»

«A TransferException was encountered while trying to contact the daemon, please ensure it’s online and accessible. This error has been logged.»

# Basic Debugging Steps

Ensure you have AdBlock disabled or whitelisted for your Panel and Daemon domains.

Check your browser’s console by pressing Ctrl + Shift + J (in Chrome) or Cmd + Alt + I (in Safari). If there is a red error in it, chances are that it will narrow down the potential problem.

Make sure if the daemon is properly installed and the active configuration matches the configuration shown under Admin -> Node -> Configuration in the Panel.

Check that the Daemon is running, and not reporting errors. Use service wings status to check the current status of the process.

Check that the Daemon ports are open on your firewall. The Daemon uses ports 8080 or 8443 for HTTP traffic, and 2022 for SFTP traffic.

Check that the Panel can reach the Daemon using the domain that is configured on the Panel. Run curl https://domain.com:8080 on the Panel server and ensure that it can connect to the Daemon.

Ensure that you are using the correct HTTP scheme for your Panel and Daemon. If the Panel is running over HTTPS the Daemon will also need to be running on HTTPS.

# More Advanced Debugging Steps

Stop the Daemon and run cd /srv/daemon; sudo npm start to see if there are any errors being output by the Daemon. If so, try resolving them manually, or contact us on Discord for more assistance.

Check your DNS and ensure that the response you receive is the one you expect using a tool such as nslookup or dig .

If you use CloudFlare make sure that the yellow cloud is disabled for your Daemon or Panel A records.

Make sure when using the daemon behind a firewall — pfSense, OpenSwitch, etc — that the correct NAT settings to access the Daemon’s ports from the outside network are setup.

If nothing is working so far, check your own DNS settings and consider switching DNS servers.

When running the Panel and Daemon on one server it can sometimes help if to add an entry in /etc/hosts that directs the public IP back to the server. Sometimes the reverse path is also needed, so you may need to add an entry to your servers /etc/hosts file that points the Panel’s domain to the correct IP.

When running the Daemon and Panel on separate VM’s using the same adapter make sure the VM’s can connect to each other. Promiscuous mode might be needed.

# Invalid MAC Exception

This error should never happen if you correctly follow our installation and upgrade guides. The only time we have ever seen this error occur is when you blindly restore the Panel database from a backup and try to use a fresh installation of the Panel.

When restoring backups you should always restore the .env file!

Sometimes when using the Panel you’ll unexpectedly encounter a broken page, and upon checking the logs you’ll see an exception mentioning an invalid MAC when decrypting. This error is caused by mismatched APP_KEY s in your .env file when the data was encrypted versus decrypted.

If you are seeing this error the only solution is to restore the APP_KEY from your .env file. If you have lost that original key there is no way to recover the lost data.

# SELinux Issues

On systems with SELinux installed you might encounter unexpected errors when running redis or attempting to connect to the daemon to perform actions. These issues can generally be resolved by executing the commands below to allow these programs to work with SELinux.

Источник

«500 Server Error» while fetching node information #4149

Current Behavior

The panel makes continous requests to admin/nodes/view/1/system-information to get the currently looked at node’s information, whicht is the expected behaivor.
The problem is that the request only returns a 500 error with the following response:

I’ve tried looking at the code for a possible sorce for the error, but I haven’t found anything useful.
The error also doesn’t produce any logs for some reason (believe me when I say that I tried finding any).

Expected Behavior

The Panel’s server returns the servers information normaly

Steps to Reproduce

I’ve freshly installed the panel via the docker image using docker-compose with the following settings:

The node is a fresh install of Debian Bullseye and Wings (no other modifications)

I’ve added an location and the node to the panel, and the system health check works in the node list, but when I look at the node the error occures continously

Panel Version

Wings Version

Games and/or Eggs Affected

Docker Image

Error Logs

Is there an existing issue for this?

• I have searched the existing issues before opening this issue.
• I have provided all relevant details, including the specific game and Docker images I am using if this issue is related to running a server.
• I have checked in the Discord server and believe this is a bug with the software, and not a configuration issue with my specific system.

The text was updated successfully, but these errors were encountered:

Have you pulled the panel and wings logs yet for this? So have all you have is «500 error» which can be any number of things.

I’ve already tried getting any logs out of the Panel (as I already mentioned in the issue), but this hasn’t been successful yet.
Also, I checked the incomming trafic for my Wings server, and there isn’t really anything from the Panel server, so that’s probably not the issue (running with the debug option also doesn’t show anything).
It also can’t be my firewall, as all ports that pterodactyl uses are opened.
Nothing produces any logs anywhere, so I’m pretty clueless on where the issue is.

If your panel isn’t reaching your wings instance than that would cause issues.

Closing, no actionable logs.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

500 Internal Server Error #2530

Background:

• Panel or Daemon: Panel & Wings
• Version of Panel/Daemon: Panel@1.0.1 — Wings@1.0.0
• Server’s OS: Debian 10
• Your Computer’s OS & Browser: Brave (chromium based browser)

Describe the bug
This bug did not occur on the latest release candidate, but I noticed that my status page, which periodically checks the status of the servers using the Client API, was recording some failures after updating my panel and wings.

So as soon as I received the failure notification, I rushed to the panel to see what was going on, and I saw an internal server 500 error in the console following a request to the /api/client/servers//resources endpoint:
Failed to load the resource: the server responded with a status of 500 (Internal Server Error) .

I changed the disk_check_interval field in the configuration because checking disk usage takes about 5 minutes, and the default delay is close to that, so it was far from ideal in my configuration, so I set it to 7200 .

I think the 500 error occurs when the disk usage check is in progress (given its recurrence)

Panel: php -v » PHP 7.4.8
Daemon: uname -a and docker info » Linux vps-ee197cf8 4.19.0-10-cloud-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux

To Reproduce
Steps to reproduce the behavior:

1. Edit the disk_check_interval field to an higher value
2. Visit the panel while the check is in progress (or use a tool to periodically check the endpoint of the api like Statping)
3. Open the browser console
4. See error

Expected behavior
Same behavior before version 1.0.0, no error 500 when the disk usage check is running.

The text was updated successfully, but these errors were encountered:

Источник

[oci runtime error ] 500 Server Error upon Creation of Source Server #253

Hello! I’m having issues while creating a new source server. Upon initial start of the server, this error appears.

npm version returns the following.

The text was updated successfully, but these errors were encountered:

Could you please reformat that? Use three ` instead of one for code blocks and try to do something about that insane amount of slashes.

Sorry @schrej, don’t use GitHub issues a lot. I fixed it to a degree.

@Brad126735 No worries, it’s much better now 😉

Any more info like OS/distro, docker version

My apologies @parkervcp.
Distro — CentOS 7.3.1611
Docker Version — 1.12.5, build 7392c3b

@Brad126735 Is there anymore of that error available? Like anything before or after?

This is the full trace from daemon/logs. @DaneEveritt

Are you running the daemon as root?

There seems to be discussion of the issue in moby/moby#28109

Yes, the daemon is being run as root, should it be otherwise? @DaneEveritt

No, that is correct. Can you provide the docker logs themselves from when this occurs?

I believe CentOS is /var/log/daemon.log | grep docker but potentially journalctl -u docker.service .

This is my current docker log.

Appears issue is being caused by /etc/timezone being an empty folder rather than a file.

Shouldn’t it be using /etc/localtime instead of /etc/timezone ? At least, on CentOS 6 and 7, that is where the system timezone is specified.

Anyway, I’m seeing the following in my daemon error.log:

• OS is CentOS 7 (image created by Limestone Networks, using their own internal CentOS repos for official packages)
• Kernel is 3.10.0-514.2.2.el7.x86_64
• Node.js version is 6.9.4 downloaded from here:
  • https://nodejs.org/dist/v6.9.4/node-v6.9.4-linux-x64.tar.xz
• Docker packages that are installed ( yum list installed | grep docker ), using official Docker repo for CentOS:

As shared with me by @DaneEveritt, you could either edit this line in (daemon directory)/src/controllers/docker.js to use the proper location of the directory. https://github.com/Pterodactyl/Daemon/blob/develop/src/controllers/docker.js#L375

Or you could delete the directory at /etc/timezone (it’s empty) and replace it with a new text file containing your timezone. (chmod 644)

A temporary fix, assuming this is fixed in the next release.

Even after replacing /etc/timezone with /etc/localtime in Docker.js I’m still getting this error every time I try to start the ARK server:

I can’t find any other files that this is defined in. Is it possible for Node.js or Docker to have cached an old copy of the script somewhere?

I even tried rebooting the server, and I still get the same error.

Ah, you have to rebuild the container. Now it’s working. 🙂

Alright, so this issue is confirmed as being CentOS based and we need to do some directory checking to determine wether or not to use /etc/timezone or /etc/localtime

I have the same problem and it somewhat fixed it but when I try to rebuild the container it says:

/start.sh: line 8: [: /home/container: integer expression expected

• curl -sSL -o steamcmd.tar.gz http://media.steampowered.com/installer/steamcmd_linux.tar.gz
  curl: (6) Could not resolve host: media.steampowered.com
• set +x
  tar (child): steamcmd.tar.gz: Cannot open: No such file or directory
  tar (child): Error is not recoverable: exiting now
  tar: Child returned status 2
  tar: Error is not recoverable: exiting now
  Installing requested game, this could take a long time depending on game size and network.
• ./steamcmd.sh +login anonymous +force_install_dir /home/container +app_update 232250 +quit
  /start.sh: line 30: ./steamcmd.sh: No such file or directory
• set +x
  cp: cannot stat ‘steamcmd/linux32/steamclient.so’: No such file or directory
  ./srcds_run -game tf -console -port 27000 +map cp_dustbowl -strictportbind -norestart
  /start.sh: line 49: ./srcds_run: No such file or directory
  (Daemon) Server detected as stopped.
  (Daemon) Server detected as crashed! Attempting to reboot server now.

don’t know if I need to make a new or just post it here. sorry in advance

That rebuild error looks like our lack of error checking in the script. Your issue is that media.steampowered.com cannot be resolved, therefore nothing is downloaded, but the script tries to continue.

that much I knew but didn’t know why because when I used the curl command on the machine it worked but found out it was just our firewall that blocked the docker ip.

But thanks for your help didn’t expect such quick an answer.

Источник

# Reading Error Logs

If you ever encounter an unexpected error with the Panel the first thing you will likely be asked for is the logs.
To retrieve these, simply execute the command below which will output the last 100 lines of the Panel’s log file.

# Parsing the Error

When you run the command above, you’ll probably be hit with a huge wall of text that might scare you. Fear not,
this is simply a stacktrace leading to the cause of the error, and you can actually ignore almost all of it when
looking for the cause of the error. Lets take a look at some example output below, which has been truncated to
make this easier to follow with.

The first thing you’ll want to do is follow the chain of numbers up until you find #0, this will be the function that
triggered the exception. Right above line 0 you will see a line that has the date and time in brackets, [2018-07-19 00:50:24]
above for example. This line will be the human readable exception that you can use to understand what went wrong.

# Understanding the Error

In the example above we can see that the actual error was:

From this error we can determine that there was an error performing a file_put_contents() (opens new window) call, and the error was
that we couldn’t open the file because permissions were denied. Its okay if you don’t understand the error at all, but
it does help you get faster support if you’re able to provide these logs, and at least find the source of the error.
Sometimes the errors are pretty straightforward and will tell you exactly what went wrong, such as a ConnectionException
being thrown when the Panel can’t connect to the Daemon.

# Utilizing GREP

If you’re trying to go through a bunch of errors quickly, you can use the command below which will limit the results returned to only
be the actual error lines, without all of the stack traces.

# Transfer Exceptions / XHR Poll Error

If you are seeing errors similar to the examples below, chances are there is some networking related issue, or you
just don’t have a required service running.

# Example Errors

• «We were unable to connect to the main Socket.IO server, there may be network issues currently. The panel may not work as expected.»

• «A TransferException was encountered while trying to contact the daemon, please ensure it’s online and accessible. This error has been logged.»

# Basic Debugging Steps

• Ensure you have AdBlock disabled or whitelisted for your Panel and Daemon domains.

• Check your browser’s console by pressing Ctrl + Shift + J (in Chrome) or Cmd + Alt + I (in Safari). If there is
  a red error in it, chances are that it will narrow down the potential problem.

• Make sure if the daemon is properly installed and the active configuration matches the configuration shown under
  Admin -> Node -> Configuration in the Panel.

• Check that the Daemon is running, and not reporting errors. Use service wings status to check the current status of the process.

• Check that the Daemon ports are open on your firewall. The Daemon uses ports 8080 or 8443 for HTTP traffic,
  and 2022 for SFTP traffic.

• Check that the Panel can reach the Daemon using the domain that is configured on the Panel. Run curl https://domain.com:8080 on the Panel server and ensure that it can connect to the Daemon.

• Ensure that you are using the correct HTTP scheme for your Panel and Daemon. If the Panel is running over HTTPS
  the Daemon will also need to be running on HTTPS.

# More Advanced Debugging Steps

• Stop the Daemon and run cd /srv/daemon; sudo npm start to see if there are any errors being output by the Daemon.
  If so, try resolving them manually, or contact us on Discord for more assistance.

• Check your DNS and ensure that the response you receive is the one you expect using a tool such as nslookup or dig.

• If you use CloudFlare make sure that the yellow cloud is disabled for your Daemon or Panel A records.

• Make sure when using the daemon behind a firewall — pfSense, OpenSwitch, etc — that the correct NAT settings to access
  the Daemon’s ports from the outside network are setup.

• If nothing is working so far, check your own DNS settings and consider switching DNS servers.

• When running the Panel and Daemon on one server it can sometimes help if to add an entry in /etc/hosts that directs
  the public IP back to the server. Sometimes the reverse path is also needed, so you may need to add an entry to your
  servers /etc/hosts file that points the Panel’s domain to the correct IP.

• When running the Daemon and Panel on separate VM’s using the same adapter make sure the VM’s can connect to each
  other. Promiscuous mode might be needed.

# Invalid MAC Exception

Sometimes when using the Panel you’ll unexpectedly encounter a broken page, and upon checking the logs you’ll see
an exception mentioning an invalid MAC when decrypting. This error is caused by mismatched APP_KEYs in your .env file
when the data was encrypted versus decrypted.

If you are seeing this error the only solution is to restore the APP_KEY from your .env file. If you have lost that
original key there is no way to recover the lost data.

# SELinux Issues

On systems with SELinux installed you might encounter unexpected errors when running redis or attempting to connect
to the daemon to perform actions. These issues can generally be resolved by executing the commands below to allow
these programs to work with SELinux.

# Redis Permissions Errors

# In case there is any weirdness with parts of the panel

# Daemon Connection Errors

# FirewallD issues

If you are on a RHEL/CentOS server with firewalld installed you may have broken DNS.

restart docker and wings after running these to be sure the rules are applied.

# Database Errors

# DatabaseController.php:142

The database user you are trying to use doesn’t have appropriate grants/has used incorrect password.

В статье мы расскажем, как исправить ошибку (код состояния) 500 со стороны пользователя и администратора сайта, а также подробно разберём, что такое ошибка запроса 500.

Что такое внутренняя ошибка сервера 500

Код ошибки 5хх говорит о том, что браузер отправил запрос корректно, но сервер не смог его обработать. Что значит ошибка 500? Это проблема сервера, причину которой он не может распознать.

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

• Внутренняя ошибка сервера 500,
• Ошибка 500 Internal Server Error,
• Временная ошибка (500),
• Внутренняя ошибка сервера,
• 500 ошибка сервера,
• Внутренняя ошибка HTTP 500,
• Произошла непредвиденная ошибка,
• Ошибка 500,
• HTTP status 500 internal server error (перевод ― HTTP статус 500 внутренняя ошибка сервера).

Дизайн и описание ошибки 500 может быть любым, так как каждый владелец сайта может создать свою версию страницы. Например, так выглядит страница с ошибкой на REG.RU:

Как ошибка 500 влияет на SEO-продвижение

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

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

Проверить, осталась ли страница на прежних позициях, можно с помощью Google Search Console. Если робот исключил страницу из поисковой выдачи, её можно добавить снова.

Код ошибки 500: причины

Если сервер вернул ошибку 500, это могло случиться из-за настроек на web-хостинге или проблем с кодом сайта. Самые распространённые причины:

• ошибки в файле .htaccess,
• неподходящая версия PHP,
• некорректные права на файлы и каталоги,
• большое количество запущенных процессов,
• большие скрипты,
• несовместимые или устаревшие плагины.

Решить проблему с сервером можно только на стороне владельца веб-ресурса. Однако пользователь тоже может выполнить несколько действий, чтобы продолжить работу на сайте.

Что делать, если вы пользователь

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

Перезагрузите страницу

Удаленный сервер возвращает ошибку не только из-за серьёзных проблем на сервере. Иногда 500 ошибка сервера может быть вызвана небольшими перегрузками сайта.

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

• на ПК — F5,
• на ноутбуке — Fn + F5,
• на устройствах от Apple — Cmd + R.

Обратите внимание! Если вы приобретаете товары в интернет-магазине и при оформлении заказа появляется 500 Internal Server Error (перевод — внутренняя ошибка сервера), при перезагрузке страницы может создаться несколько заказов. Поэтому сначала проверьте, оформился ли ваш предыдущий заказ. Если нет, попробуйте оформить заказ заново.

Очистите кэш и cookies браузера

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

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

Что делать, если вы владелец сайта

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

Ниже рассмотрим самые популярные причины и способы решения.

Ошибки в файле .htaccess

Неверные правила в файле .htaccess — частая причина возникновения ошибки. Чтобы это проверить, найдите .htaccess в файлах сайта и переименуйте его (например, в test). Так директивы, прописанные в файле, не повлияют на работу сервера. Если сайт заработал, переименуйте файл обратно в .htaccess и найдите ошибку в директивах. Если вы самостоятельно вносили изменения в .htaccess, закомментируйте новые строки и проверьте доступность сайта.Также может помочь замена текущего файла .htaccess на стандартный в зависимости от CMS.

Найти директиву с ошибкой можно с помощью онлайн-тестировщика. Введите содержимое .htaccess и ссылку на сайт, начиная с https://. Затем нажмите Test:

Произошла непредвиденная ошибка

На экране появится отчёт. Если в .htaccess есть ошибки, они будут выделены красным цветом:

500 ошибка nginx

Активирована устаревшая версия PHP

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

Установлены некорректные права на файлы и каталоги сайта

В большинстве случаев корректными правами для каталогов являются «755», для файлов — «644». Проверьте, правильно ли они установлены, и при необходимости измените права на файлы и папки.

Запущено максимальное количество процессов

На тарифах виртуального хостинга REG.RU установлены ограничения на количество одновременно запущенных процессов. Например, на тарифах линейки «Эконом» установлено ограничение в 18 одновременно запущенных процессов, на тарифах «+Мощность» ― 48 процессов. Если лимит превышен, новый процесс не запускается и возникает системная ошибка 500.

Такое большое число одновременных процессов может складываться из CRON-заданий, частых подключений с помощью почтовых клиентов по протоколу IMAP, подключения по FTP или других процессов.

Чтобы проверить количество процессов, подключитесь по SSH. Выполните команду:

ps aux | grep [u]1234567 |wc -l

Вместо u1234567 укажите ваш логин хостинга: Как узнать логин хостинга.

Чтобы посмотреть, какие процессы запущены, введите команду:

Вместо u1234567 укажите логин услуги хостинга.

Командная строка отобразит запущенные процессы:

Код ошибки 500

Где:

• u1234567 — логин услуги хостинга,
• 40522 — PID процесса,
• S — приоритет процесса,
• /usr/libexec/sftp-server — название процесса.

Процесс можно завершить командой kill, например:

Вместо 40522 укажите PID процесса.

Чтобы решить проблему, вы также можете:

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

Если вам не удалось самостоятельно устранить ошибку 500, обратитесь в техподдержку.

Скрипты работают слишком медленно

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

У пользователей VPS есть возможность увеличить максимальное использование оперативной памяти на процесс, но лучше делать скрипты меньшего размера.

Ошибка 500 на сайте, созданном на WordPress

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

Для начала проверьте, нужно ли обновить плагины. Часто устаревшие плагины перестают работать и вызывают проблемы работы сайта. Если все плагины обновлены, но 500 Internal Server Error остаётся, отключите все плагины, чтобы убедиться, что именно они мешают работе сайта. Как только станет понятно, что виноват один из плагинов, отключайте их по очереди, пока не найдёте тот, который нарушает работу сервера.

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

Содержание:

• Что означает код ошибки 500 и почему она возникает?
• Где можно встретить ошибку 500?
• Все причины возникновения ошибки
• Что делать при появлении ошибки? 
  • Подождать
  • Сообщить администратору
• Что делать администратору при появлении ошибки? 
  • Проверить файл htaccess
  • Проверить лог ошибок
  • Проверить содержимое CGI-скриптов
  • Проверить плагины и компоненты
  • Увеличить объем оперативной памяти сервера

Что означает код ошибки 500 и почему она возникает?

Коды состояния HTTP сообщают браузеру интернет-пользователя (клиенту), успешно ли выполнен запрос (получение доступа к сайту). К примеру, если браузер получает код состояния 200, то все прошло успешно. Это сообщение не видно пользователю — вместо него появляется запрошенный контент.

С кодами состояния 400 и 500 дело обстоит иначе. Первый означает, что ошибка связана с клиентом, а второй — с сервером.

Internal Server Error 500 — общий код состояния для ошибок со стороны сервера. По этой причине невозможно сразу определить, где именно возникла проблема: известно лишь то, что сервер сообщил о ней. Когда это происходит, сайт отображает посетителям страницу с сообщением об ошибке.

Где можно встретить ошибку 500?

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

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

• 500 Internal Server Error;
• HTTP 500 — Internal Server Error;
• Temporary Error (500);
• Internal Server Error;
• HTTP 500 Internal Error;
• 500 Error;
• HTTP Error 500;
• 500. That’s an error.

Обычно эта ошибка отображается в окне браузера, как стандартная веб-страница.

Все причины возникновения ошибки

Internal Server Error 500 возникает, когда запрос обрабатывается сервером. Этот код состояния включает все незапланированные события, которые могут произойти на стороне сервера и помешать загрузке сайта. Одна из возможных причин — ошибка в конфигурации сервера.

Вот несколько типичных источников проблем.

• Доступ запрещен — разрешения основных файлов и папок заданы неправильно.
• Тайм-аут сеанса PHP — скрипт пытается получить доступ к внешнему ресурсу и сталкивается с задержкой.
• Некорректный код в htaccess — структура htaccess, файла для локальной настройки сервера Apache, может быть неправильной.
• Ошибка в синтаксисе и коде скриптов CGI и Perl — в этих скриптах могут встречаться неточности, в частности несогласованность путей.
• Лимит памяти PHP — процесс превышает пределы памяти и поэтому не может быть выполнен правильно.

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

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

Что делать при появлении ошибки?

Если вы попытались открыть веб-страницу, но увидели Internal Server Error 500, можно сделать следующее.

Подождать

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

Также можно заглянуть на сайт downforeveryoneorjustme.com и вставить в поисковую строку URL-адрес страницы, на которой произошла внутренняя ошибка сервера.

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

Сообщить администратору

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

У большинства сайтов и сервисов есть аккаунты в социальных сетях, а на некоторых даже указаны email-адреса и номера телефона.

Что делать администратору при появлении ошибки?

Если ошибка 500 появилась на вашем сайте, попробуйте следующие способы.

Проверить файл htaccess

Загляните в файл htaccess: даже небольшая синтаксическая ошибка может вызывать внутреннюю ошибку сервера. Не менее часто случается так, что этот файл неправильно отформатирован. Его нужно создавать в формате ASCII или ANSI, а не в Unicode. Следовательно, писать его следует в текстовом редакторе, например в Notepad, Notepad++ и Sublime Text, а не в Microsoft Word.

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

Проверить лог ошибок

Загляните в лог-файл, например для серверов Linux его можно найти по адресу /var/log/httpd/error_log. Попробуйте перезагрузить сайт, чтобы воспроизвести код ошибки 500, и посмотреть, как создается лог-файл. Это поможет быстро найти источник проблемы.

Проверить содержимое CGI-скриптов

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

• read (r) — чтение;
• write (w) — запись;
• execute (x) — выполнение.

Эти разрешения можно предоставлять трем типам пользователей:

• владельцу файла;
• группе пользователей;
• все остальным.

Права указываются либо с помощью сокращений r, w и x, либо с помощью числовых значений: 4 — для чтения, 2 — для записи и 1 — для выполнения. Они добавляются для каждого типа пользователей и идут один за другим: rwxr-xr-x (rwx — для владельца, r-x — для группы и r-x — для всех остальных) или 755.

По умолчанию должна быть установлена конфигурация 755. Если разрешения предоставляются иначе, может возникнуть ошибка. Эту настройку можно изменить с помощью команды: chmod 755 filename.

Если проблема не решится, можно также провести тестирование, предоставив все права для каждой группы: chmod 777 filename. Однако к этой настройке следует прибегать только для определения проблемы — если любой пользователь сможет переписывать файл, безопасность сайта окажется под угрозой.

Проверить плагины и компоненты

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

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

Увеличить объем оперативной памяти сервера

Лимит памяти определяет, какой ее объем может задействовать процесс. Если какой-либо процесс требует больше памяти, чем доступно, может возникать ошибка 500.

Чтобы это исправить, можно временно увеличить лимит памяти. Для этого добавьте в php.ini команду, подобную этой: memory_limit = 512M. Этот пример устанавливает лимит на 512 МБ.

Учитывайте, что хостинг-провайдер допускает лишь определенный лимит сеанса PHP в рамках используемого вами пакета. Если будет введено большее значение, сервер проигнорирует его. Также помните, что это лишь временное решение: как только сайт заработает, потребуется выяснить причину высокого потребления памяти. Высока вероятность, что в коде содержится ошибка.

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

В статье использовались материалы следующих источников:

Blog.hubspot.com 

Ionos.com

Businessinsider.com

Lifewire.com