Как исправить 500 ошибку Internal Server Error при заходе в админку битрикса после переноса с тестового на боевой?

при переносе с тестового хостинга на боевой , когда заходим по ссылке http://имя_сайта/bitrix/admin/ или http://имя_сайта/bitrix/admin/index.php… выдаёт 500 ошибка Internal Server Error
при этом, если ввести http://имя_сайта/bitrix/admin/gfdggfdg, то уже заходит, выдаёт 404 в самой админке и уже можно по ней перемещаться и работать в ней. Есть идеи в чем дело, куда копать и как исправить?
ТП хостинга сказала, что у неё нет идей решения проблемы.

лог апача, который к этой проблеме относится:
[Tue Oct 08 16:57:32.512957 2019] [core:error] [pid 2283] [client 95.79.108.23:64931] End of script output before headers: index.php, referer: http://имя_сайта/bitrix/admin/

код файла .htaccess:

Options -Indexes 
ErrorDocument 404 /404.php

<IfModule mod_php5.c>
  php_flag session.use_trans_sid off
  #php_flag default_charset UTF-8
  #php_value display_errors 1
</IfModule>

<IfModule mod_php7.c>
  php_flag session.use_trans_sid off
  #php_flag default_charset UTF-8
  #php_value display_errors 1
</IfModule>

<IfModule mod_rewrite.c>
  Options +FollowSymLinks
  RewriteEngine On
			
	# ASPRO_ROBOTS Serve robots.txt with robots.php only if the latter exists
	RewriteCond %{REQUEST_FILENAME} robots.txt
	RewriteCond %{DOCUMENT_ROOT}/robots.php -f
	RewriteRule ^(.*)$ /robots.php [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-l
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
  RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]
  RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]
</IfModule>

<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>

<IfModule mod_expires.c>
  ExpiresActive on
  ExpiresByType image/jpeg "access plus 3 day"
  ExpiresByType image/gif "access plus 3 day"
  ExpiresByType image/png "access plus 3 day"
  ExpiresByType text/css "access plus 3 day"
  ExpiresByType application/javascript "access plus 3 day"  
</IfModule>

Проверка и устранение ошибок Bitrix 🚀

 

 

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

 

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

Bitrix долго грузится каталог

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

• Кеширование
  Убедитесь, что все используемые на странице каталога компоненты используют кеширование.
• Компоненты
  Какой бы мощный сервер вы не купили, если на странице несколько десятков комплексных компонентов 1С-Битрикс, то как минимум в момент разогрева кеша скорость загрузки страницы у вас будет несколько секунд. Постарайтесь снизить количество используемых компонентов.
• Композитный сайт
  Обязателен к включению в интернет-магазинах.
• Мониторинг производительности. Вообще этот пункт должен быть первым, но он требует технических навыков. Встроенный инструмент анализа производительности Битрикса — полезная штука. Для быстрого анализа сразу ищем – медленные SQL-запросы, так как база данных всегда самое слабое звено.
• PHP
  На сервере должна использоваться версия PHP не ниже 7.1. Если такой возможности нет, то хотя бы для 5.6 должны стоят акселераторы на выбор: XCache, eAccelerator, APC.
• Nginx
  В качестве веб-сервера рекомендуем использовать более производительней сервер Nginx отечественной разработки.

Bitrix ошибка отсутствуют цены

Самая простая и распространная ошибка, которую ошибкой даже тяжело назвать. В Битриксе есть несколько типов цен (Магазин > Настройки > Цены > Типы цен). Удаляете ненужные, в настройках компонента каталога/новинок и других связанных с магазином выставляете нужный тип цены.

Ошибка в типе содержимого bitrix

Ошибка не появляется на ровном месте, значит недавно были правки или вообще переезд на другой сервер. В каком-то из файлов, в результате ошибки php или кодировки файла при сохранении, идет вывод содержимого страницы (текст ошибки это тоже текст) до служебных http-заголовков. Рекомендуем в первую очередь посмотреть недавно отредактированные файлы на предмет кодировки UTF-8 с BOM и сделать UTF-8 без BOM.

Например так:

grep -rl $'\xEF\xBB\xBF' .

500 ошибка bitrix

Ошибка 500 Internal Server Error или «Белый экран смерти» требует дополнительной диагностики. Для этого и нужен error.log веб-сервера, а также режим отладки самого Битрикс. Чаще всего это синтаксические ошибки в php-файлах или .htaccess, которые легко можно найти по последним записям логов или дате последнего редактирования файлов на сервере.

Не работает сео битрикс

Переключите шаблон компонента на стандартный, чтобы исключить вероятность ошибки в кастомизированном под ваш сайт шаблоне компонента. Проверьте корректность настроек вывода компонента. Для работы с SEO комплекстные компоненты, на примере компонента новостей имеют отдельные настройки: SET_META_KEYWORDS, SET_META_DESCRIPTION.

 

Возможно вам будет интересно

 

Экономьте свое время — делегируйте работу с Битрикс нам

Сложно? Только не для нас!

Мы оказываем техническую поддержку сайтов на Битрикс с 2010 года. Яндекс официально рекомендует наш модуль для работы с собственным сервисом турбо-страниц.

Бесплатная консультация 8 (499) 577-01-09

 

2 октября 2019 Техническая поддержка

1С-Битрикс Разработчикам — Частые вопросы

Что такое?

Это вставка в код страницы сайта определенного зашифрованного JavaScript-кода, при выполнении которого формируется так называемый iframe (HTML-элемент, позволяющий включить при отображении содержимое одной страницы в другую). Вставленный iframe указывает, как правило, на зараженную страницу, которая уже содержит более «тяжелый» код, использующий различные уязвимости браузеров (в основном Internet Explorer’а) для загрузки и запуска исполняемых файлов вирусов.

Механизм заражения

Механизм заражения сайтов в подавляющем числе случаев одинаков: вирус попадает на компьютер, с которого выполнялся вход на данный сайт по протоколу FTP, после чего получает реквизиты доступа к адресам, для которых в программе FTP-клиенте была выбрана опция «запомнить логин/пароль». Получив реквизиты доступа, вирус отсылает их на компьютеры злоумышленников, где уже и расположены программы-роботы, выполняющие «грязную» работу. Эти роботы выполняют подключение к FTP-адресам с полученными реквизитами, затем сканируют каталоги сайта в поисках файлов с определенными именами: чаще всего это корневые файлы — те, к которым в первую очередь выполняется обращение при входе на сайт. Обнаружив такой файл, робот скачивает его, добавляет в конец скачанного файла вредоносный код, и закачивает этот файл обратно на FTP-сервер, заменяя оригинал.

С точки зрения сервера это выглядит как обыкновенная активность пользователя: выполняется подключение авторизованного пользователя, скачивание и закачивание файлов — фактически именно то, что выполняется при обыкновенном обновлении сайта разработчиком по FTP.

Устранение заражения

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

Также, Вы можете запросить у администратора хостинга все возможные логи (логи ftp, логи веб-сервера, ssh логи). Полученные логи от администратора необходимо проанализировать на предмет времени модификации файлов и способа доступа к ним, а также IP-адресов, с которых производилось изменение, что позволить сузить круз проблемных ПК, а также определить способ доступа к файлам и их заражение.

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

Предотвращение заражения

Для того, чтобы не повторять чужих ошибок и уберечься от повреждения сайта, достаточно следовать простым рекомендациям:
— не использовать возможности FTP-клиентов по сохранению паролей;
— периодически выполнять смену паролей доступа к FTP;
— при необходимости, ограничить адреса компьютеров, с которых разрешено подключаться по FTP;
— использовать для доступа по FTP только «надежные» компьютеры — те, на которых установлены антивирусы с актуальными базами обновлений.

Использовался материал с сайта: www.netangels.ru/support/howto/ftp-infection/

Поиск вирусов и лечение скриптов: http://dev.1c-bitrix.ru/community/blogs/howto/1051.php

Если на сайте обнаружен вирус: http://dev.1c-bitrix.ru/community/blogs/information_security/1899.php

Наверх

Как исправить 500 ошибку в битрикс? — Хабр Q&A

Здравствуйте! Исправлял файлы сайта через FTP и получил 500 ошибку) Залил обратно те же файлы что были до исправления на FTP и все равно ошибка осталась, возможно проблема в .htaccess Вот код из него

Options -Indexes 
ErrorDocument 404 /404.php


<IfModule mod_php5.c>
  php_flag allow_call_time_pass_reference 1
  php_flag session.use_trans_sid off

  #php_value display_errors 1

  #php_value mbstring.func_overload 2
  #php_value mbstring.internal_encoding UTF-8
</IfModule>

<IfModule mod_rewrite.c>
  Options +FollowSymLinks
  RewriteEngine On

  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_URI} !\..+$
  RewriteCond %{REQUEST_URI} !/$
  RewriteRule (.*) http://ludacha.ru/$1/ [R=301,L]

  RewriteCond %{HTTP_HOST} ^www.ludacha.ru [NC]
  RewriteRule ^(.*)$ http://ludacha.ru/$1 [L,R=301]

  RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ (.*)/index\.php\ HTTP/
  RewriteRule ^(.*)index\.php$ http://ludacha.ru/$1 [L,R=301]

  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-l
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
  RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]
  RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]
</IfModule>

<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>

<IfModule mod_expires.c>
  ExpiresActive on
  ExpiresByType image/jpeg "access plus 3 day"
  ExpiresByType image/gif "access plus 3 day"
  ExpiresByType image/png "access plus 3 day"
  ExpiresByType text/css "access plus 3 day"
  ExpiresByType application/javascript "access plus 3 day"  
</IfModule>

В админку входит отлично и файлы тоже спокойно редачатся, может слетели настройки index-ной страницы? Подскажите как исправить. Также пропали надписи joxi.ru/Y2Lzp7yTnDjL8r

error_log

[Mon Dec 11 00:01:02 2017] [error] [client 141.8.132.35] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 00:01:06 2017] [error] [client 141.8.132.35] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 00:43:54 2017] [error] [client 181.48.9.82] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 05:56:51 2017] [error] [client 207.46.13.128] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 08:01:49 2017] [error] [client 157.55.39.22] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 08:01:51 2017] [error] [client 157.55.39.22] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 08:10:17 2017] [error] [client 40.77.167.42] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 09:26:31 2017] [error] [client 139.162.116.133] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 11:14:49 2017] [error] [client 157.55.39.95] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 11:19:58 2017] [error] [client 207.46.13.128] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 14:22:52 2017] [error] [client 164.52.7.131] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 14:47:24 2017] [notice] Graceful restart requested, doing restart
[Mon Dec 11 14:47:28 2017] [warn] RSA server certificate CommonName (CN) `ludacha.ru' does NOT match server name!?
[Mon Dec 11 14:47:28 2017] [notice] Apache/2.2.16 (Debian) mod_fcgid/2.3.6 PHP/5.3.3-7+squeeze19 with Suhosin-Patch mod_ssl/2.2.16 OpenSSL/0.9.8o configured -- resuming normal operations
[Mon Dec 11 14:48:30 2017] [notice] Graceful restart requested, doing restart
[Mon Dec 11 14:48:31 2017] [warn] RSA server certificate CommonName (CN) `ludacha.ru' does NOT match server name!?
[Mon Dec 11 14:48:31 2017] [notice] Apache/2.2.16 (Debian) mod_fcgid/2.3.6 PHP/5.3.3-7+squeeze19 with Suhosin-Patch mod_ssl/2.2.16 OpenSSL/0.9.8o configured -- resuming normal operations
[Mon Dec 11 14:54:57 2017] [notice] caught SIGTERM, shutting down
[Mon Dec 11 14:56:03 2017] [warn] RSA server certificate CommonName (CN) `ludacha.ru' does NOT match server name!?
[Mon Dec 11 14:56:03 2017] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Mon Dec 11 14:56:09 2017] [warn] RSA server certificate CommonName (CN) `ludacha.ru' does NOT match server name!?
[Mon Dec 11 14:56:09 2017] [notice] Apache/2.2.16 (Debian) mod_fcgid/2.3.6 PHP/5.3.3-7+squeeze19 with Suhosin-Patch mod_ssl/2.2.16 OpenSSL/0.9.8o configured -- resuming normal operations
[Mon Dec 11 14:57:00 2017] [error] [client 95.161.153.62] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 14:57:01 2017] [error] [client 95.161.153.62] File does not exist: /etc/apache2/htdocs, referer: https://109.120.136.198/var/www/ludacha/data/www/ludacha.com
[Mon Dec 11 14:57:05 2017] [error] [client 95.161.153.62] File does not exist: /etc/apache2/htdocs
[Mon Dec 11 15:21:15 2017] [notice] caught SIGTERM, shutting down
[Mon Dec 11 15:21:16 2017] [warn] RSA server certificate CommonName (CN) `ludacha.ru' does NOT match server name!?
[Mon Dec 11 15:21:16 2017] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Mon Dec 11 15:21:17 2017] [warn] RSA server certificate CommonName (CN) `ludacha.ru' does NOT match server name!?
[Mon Dec 11 15:21:17 2017] [notice] Apache/2.2.16 (Debian) mod_fcgid/2.3.6 PHP/5.3.3-7+squeeze19 with Suhosin-Patch mod_ssl/2.2.16 OpenSSL/0.9.8o configured -- resuming normal operations