Diagnosing and troubleshooting 500 errors on 1C-Bitrix

Diagnostics and Resolution of 500 Errors on 1C-Bitrix

HTTP 500 — Internal Server Error — means the server couldn't process the request, but doesn't say why. In Bitrix context this is most frequent and most annoying failure type: user sees standard error page, but admin panel may have no records. Reason is 500 error occurs before Bitrix initializes its logging system. Let's explore where to look for real cause and how to fix it.

Why Bitrix is Silent on 500

Bitrix initialization chain: index.php → header.php → /bitrix/modules/main/include/prolog_before.php → DB connection → modules initialization → URL processing → component call. If PHP process crashes at any stage before exception_handling initialization from .settings.php, Bitrix can't log error to its journal. Only web server log and PHP remain.

Diagnostics Algorithm

Step 1. Find error log.

Check in following order:

1. PHP error log — path determined by error_log directive in php.ini or php-fpm pool config. Typical locations: /var/log/php-fpm/www-error.log, /var/log/php/error.log.
2. Web server log — for nginx: /var/log/nginx/error.log, for Apache: /var/log/apache2/error.log or /var/log/httpd/error_log.
3. Bitrix log — /bitrix/modules/main/tools/log.txt (if configured) and event log in DB.

If all three logs empty — PHP process killed by OOM-killer or segfault. Check /var/log/syslog or dmesg for Out of memory: Kill process or segfault entries.

Step 2. Determine which URL causes error.

500 can be global (all pages) or local (specific section). This narrows search immediately:

Step 3. Reproduce with debug enabled.

Temporarily add to index.php start (before Bitrix include):

ini_set('display_errors', 1);
error_reporting(E_ALL);

Or create separate test file test500.php with minimal kernel include:

require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php';
echo 'Kernel loaded';

If this file returns 500 — problem is in core or config. If works — problem in specific template or component.

Main Causes and Solutions

1. Memory limit exhaustion.

Most common cause. Bitrix consumes 128-256 MB on typical catalog page. Mass operations (import, search index building) can require 512 MB and more.

Log symptom: Allowed memory size of N bytes exhausted. Solution: increase memory_limit in php.ini or .htaccess to 256M-512M. If consumption is abnormally high — profile via xdebug or Blackfire: possible memory leak in element processing loop.

2. Errors in init.php and dbconn.php.

File /bitrix/php_interface/init.php included on each hit. Syntax error or Fatal Error in it downs entire site. Similarly dbconn.php (deprecated, but often modified file with DB connection params).

Check: rename init.php to init.php.bak. If site works — error is in it. Restore file and search problem line via binary search: comment half of code, check, narrow down.

3. .htaccess conflict.

Bitrix creates .htaccess in root and /bitrix/. Directives php_value, php_flag cause 500 if PHP runs via php-fpm (not as Apache module). Also error occurs with mod_rewrite with incorrect rules.

Check: temporarily rename .htaccess. If works — problem in directives. Remove php_value/php_flag and move settings to php.ini or pool config.

4. MySQL/MariaDB crash.

Bitrix returns 500 on inability to connect to DB (if error page not configured). Check service status: systemctl status mysql. Common cause — OOM-killer killed mysqld process.

In Bitrix log: DB query error. In MySQL log: InnoDB: Fatal error: cannot allocate memory. Solution: configure innodb_buffer_pool_size appropriately to available RAM, add swap, or migrate to server with sufficient memory.

5. Errors in components and templates.

If 500 occurs on specific page — problem in component. Typical causes:

• result_modifier.php calls non-existent method after module update
• Component template accesses $arResult['PROPERTIES']['DELETED_PROP']
• Component uses CIBlockElement::GetList() with incorrect filter causing MySQL error

For isolation: replace component template content with <?php print_r($arResult);?>. If page works — error in template.

Preventive Measures

• Configure exception_handling in .settings.php with file logging — even on partial kernel initialization this increases chances of getting stack trace.
• Monitor memory_limit with margin — if average hit consumes 180 MB at 256 MB limit, any spike causes 500.
• Separate cron processes and web processes into different php-fpm pools with different memory_limit — import with 1 GB limit won't affect normal hits.
• Test updates on site copy. Command php /bitrix/modules/main/tools/update_system.php allows updating from CLI, simplifying rollback.