Magento 2 Blank Page on Frontend & Admin: The Complete Fix Guide

What “blank page” actually means in Magento 2

Browsers display a blank page for three completely different reasons, and the fix is different for each. Before you change anything, decide which kind you have:

1. The browser never reached your server. Chrome / Firefox shows This site can’t be reached, ERR_NAME_NOT_RESOLVED, or a long load with no response. The browser cannot resolve the hostname (jjsmykker.dk, magento2.local, etc.) to an IP. Fix: the hosts file.
2. The server responded with empty HTML. Chrome shows a white page; View Source shows nothing or a tiny amount of HTML; the URL bar shows your hostname loaded cleanly. Apache did serve a response, it was just empty. Fix: PHP error or Magento mode issue.
3. The server returned a 403/404/500 dressed as a blank. The browser may show 403 Forbidden, 404 Not Found, or render Apache’s default placeholder. Fix: Apache virtual host or .htaccess.

Open Chrome DevTools → Network, reload the page, click the top request and check the Status column. That single number tells you which of the three categories you are in, and therefore which section of this guide to jump to.

Step 1 · Edit the hosts file (Linux & macOS)

If your install is on Ubuntu and you are pointing a fake domain like jjsmykker.dk or magento2.local at 127.0.0.1, the operating system needs a hosts-file entry to resolve the name. Without it, Chrome tries to look it up over real DNS, fails, and shows This site can’t be reached.

On Linux and macOS the file lives at /etc/hosts:

sudo nano /etc/hosts

Add one line per hostname that should resolve to your local machine. Use the exact hostname you put in ServerName/ServerAlias inside the Apache vhost — if they don’t match, Apache will not route the request to the right vhost block.

127.0.0.1   magento2
127.0.0.1   magento2.local
127.0.0.1   jjsmykker.dk
127.0.0.1   admin.magento2.local

Save (Ctrl+O in nano), exit (Ctrl+X), then test resolution without going through the browser at all:

ping -c 2 magento2.local
getent hosts magento2.local
curl -I http://magento2.local/

If ping answers from 127.0.0.1 and curl returns any HTTP status code (even 403 or 500), your hostname now resolves. If curl still hangs, you have a firewall or Apache listen-address problem, not a Magento problem.

Step 2 · Edit the Windows hosts file

If your Magento install is running inside WSL, a VM, or Docker on a Windows 10/11 host, and you are browsing it from Chrome on Windows, you must edit both the Ubuntu /etc/hosts file and the Windows hosts file. Chrome on Windows uses the Windows hosts file for resolution — not the WSL one.

The Windows hosts file lives at:

C:\Windows\System32\drivers\etc\hosts

It has no file extension. To edit it you need an editor running as Administrator — Notepad will silently fail to save otherwise.

1. Press Start, type notepad, right-click Notepad, choose Run as administrator.
2. In Notepad, File → Open, paste the path above into the filename box, change the file-type filter to All Files (*.*) so the extensionless hosts file shows up, and open it.
3. Add the same lines you added to /etc/hosts on Ubuntu, one per hostname:

   127.0.0.1   magento2
   127.0.0.1   magento2.local
   127.0.0.1   jjsmykker.dk

4. Save the file. Notepad may ask “keep file extension” — say yes; the file should stay called hosts with no extension.
5. Flush Windows’ DNS cache so Chrome stops using the cached “not found” result:

   ipconfig /flushdns

6. Close all Chrome windows (check the system tray) and reopen Chrome. Visit chrome://net-internals/#dns → Clear host cache, then visit chrome://net-internals/#sockets → Flush socket pools.

Verify from a Windows command prompt:

ping magento2.local

You should see replies from 127.0.0.1. If you see could not find host, the file did not save — check the path again and confirm the file is exactly hosts with no .txt extension.

Step 3 · Create the Apache virtual host (Magento-ready)

This is where the most common mistake hides. The example vhost in the original Stack Exchange answer correctly serves a static index.html at /var/www/magento2/index.html — but Magento 2 is not served from the project root. Magento ships an index.php inside the pub/ sub-directory, and that is what Apache must serve. Pointing DocumentRoot at the project root exposes app/, vendor/, and .env to the public web and breaks all the rewrites in pub/.htaccess.

The correct Magento-ready vhost looks like this. Save it as /etc/apache2/sites-available/magento2.conf:

<VirtualHost *:80>
    ServerName magento2.local
    ServerAlias jjsmykker.dk www.jjsmykker.dk
    ServerAdmin webmaster@localhost

    # Magento 2 is served from the pub/ sub-directory, NEVER the project root.
    DocumentRoot /var/www/magento2/pub

    <Directory /var/www/magento2/pub>
        Options Indexes FollowSymLinks MultiViews
        # AllowOverride MUST be All so Magento's bundled .htaccess can rewrite URLs.
        # If you set this to None, every page becomes a blank or a 404.
        AllowOverride All
        Require all granted
    </Directory>

    # Block direct access to project files outside pub/.
    <Directory /var/www/magento2/app>        Require all denied </Directory>
    <Directory /var/www/magento2/vendor>     Require all denied </Directory>
    <Directory /var/www/magento2/var>        Require all denied </Directory>
    <Directory /var/www/magento2/generated>  Require all denied </Directory>

    ErrorLog  ${APACHE_LOG_DIR}/magento2-error.log
    CustomLog ${APACHE_LOG_DIR}/magento2-access.log combined
</VirtualHost>

Enable the site, disable the default vhost so it does not race for the same :80, enable mod_rewrite (required for Magento’s URL rewrites), and reload:

sudo a2ensite magento2.conf
sudo a2dissite 000-default.conf
sudo a2enmod rewrite headers expires deflate
sudo apache2ctl configtest          # syntax check before you reload
sudo systemctl reload apache2

Verify Apache is now routing your hostname to this vhost:

curl -I http://magento2.local/
# Look for: HTTP/1.1 200 OK or 302 Found (Magento redirect). Both are fine.
# If you get 403 here, jump to Step 9 (.htaccess + AllowOverride).

Step 4 · Set Magento mode + run the right deploy commands

Magento has three modes — default, developer, and production — and the symptoms of getting them wrong are nearly identical to the blank-page problem. In production mode, Magento serves nothing unless setup:di:compile and setup:static-content:deploy have already run; if you forgot either, the storefront renders blank or unstyled and the admin sometimes returns a literal empty body.

For a local install where you are still debugging, switch to developer mode — it builds generated code on demand and surfaces every PHP error:

cd /var/www/magento2
sudo -u www-data bin/magento deploy:mode:show
sudo -u www-data bin/magento deploy:mode:set developer
sudo -u www-data bin/magento setup:upgrade
sudo -u www-data bin/magento cache:flush

Run the CLI as the web user (www-data on Ubuntu / Debian). Running it as root creates files Apache can’t read — the next request then 500s or returns blank, and the symptom looks exactly like a configuration problem.

If you want to stay in production mode, you must explicitly run the static deploy too:

sudo -u www-data bin/magento setup:upgrade
sudo -u www-data bin/magento setup:di:compile
sudo -u www-data bin/magento setup:static-content:deploy -f en_US
sudo -u www-data bin/magento cache:flush

For a deeper dive into what each of these commands actually does — phases, tables they write to, and the production-safe run order — see my breakdown of setup:upgrade, setup:di:compile, and setup:static-content:deploy.

Step 5 · Fix file and folder permissions

Magento needs to write to var/, generated/, pub/static/, pub/media/, and app/etc/. If any of these is owned by the wrong user or read-only, Magento either errors out (filling var/log/exception.log) or returns an empty body when error display is off.

cd /var/www/magento2
sudo find . -type d -exec chmod 755 {} +
sudo find . -type f -exec chmod 644 {} +
sudo chmod -R g+w var generated pub/static pub/media app/etc
sudo chmod u+x bin/magento
sudo chown -R www-data:www-data .

If you SSH in as your own user but Apache runs as www-data, add yourself to that group so you can edit files without breaking ownership:

sudo usermod -a -G www-data $USER
newgrp www-data        # apply group membership in current shell

After fixing permissions, wipe the cache and generated trees so the next request rebuilds them under the correct owner:

sudo -u www-data rm -rf var/cache/* var/page_cache/* generated/code/* generated/metadata/*
sudo -u www-data bin/magento cache:flush

Step 6 · Reveal hidden PHP errors

If the browser is showing blank but Apache returned 200, Magento started rendering and then died inside PHP — with error output suppressed. To see what actually failed, enable developer mode (Step 4) and explicitly turn on error display:

# pub/errors/local.xml — copy from the example shipped with Magento
cp pub/errors/local.xml.sample pub/errors/local.xml

# Magento 2.4: surface PHP errors
sudo -u www-data bin/magento deploy:mode:set developer
sudo -u www-data bin/magento config:set dev/debug/debug_logging 1

Then tail the three log files in three terminals and reload the blank page in Chrome:

# Terminal 1 — Magento application errors
tail -f var/log/exception.log var/log/system.log

# Terminal 2 — PHP fatal errors (Apache + PHP-FPM)
tail -f /var/log/apache2/magento2-error.log

# Terminal 3 — PHP error log (if php.ini points to a separate file)
tail -f /var/log/php_errors.log 2>/dev/null

The first real error tells you which root cause you have. Common ones to expect: Class “Magento\X\Y\Z” does not exist (composer install missed something), Allowed memory size exhausted (PHP memory_limit too low), Permission denied on var/cache (Step 5), SQLSTATE[HY000] [2002] (MySQL host unreachable from PHP).

Step 7 · Re-run setup:upgrade, indexers, and flush every cache layer

If you installed Magento via Composer but skipped setup:upgrade, the database is empty — the storefront tries to render against missing tables and returns blank. Run the full setup sequence in order, as the web user:

cd /var/www/magento2
sudo -u www-data bin/magento setup:upgrade
sudo -u www-data bin/magento setup:di:compile          # production mode only
sudo -u www-data bin/magento setup:static-content:deploy -f en_US   # production only
sudo -u www-data bin/magento indexer:reindex
sudo -u www-data bin/magento cache:flush
sudo systemctl restart php8.3-fpm                      # if using PHP-FPM
sudo systemctl reload apache2

If you use Varnish or Redis page cache, restart them too — a stale cached response from a failed earlier request will keep serving blank long after you fixed the underlying issue.

Step 8 · Confirm vendor/ is fully installed

If composer install was interrupted (network drop, disk full, wrong PHP version), the vendor/ directory is half-populated. Magento autoloads classes lazily, so the install looks fine until the first request reaches a missing class. That request returns blank.

cd /var/www/magento2
ls vendor/magento/framework 2>/dev/null && echo "vendor present" || echo "vendor MISSING"

# Re-install if anything looks short
sudo -u www-data composer install --no-dev --optimize-autoloader
sudo -u www-data composer dump-autoload

If you also see the dreaded Proxy.php: No such file or directory error during setup:di:compile, the generated/ tree is out of sync with the optimized autoloader. Recover with a two-pass autoload: composer dump-autoload (non-optimized) → bin/magento setup:di:compile → composer dump-autoload --optimize.

Step 9 · Check .htaccess and AllowOverride

Magento ships an .htaccess file inside pub/ that handles URL rewrites — the rules that turn pretty URLs like /customer/account/login into index.php?.... If Apache is told to ignore .htaccess (the default in many Ubuntu setups), every Magento URL except the front page returns blank or 404.

Check the vhost has AllowOverride All on the pub/ directory (see Step 3). Then confirm mod_rewrite is loaded:

sudo a2enmod rewrite
sudo apache2ctl -M | grep rewrite      # rewrite_module must appear
sudo systemctl reload apache2

Verify .htaccess is actually present (a fresh composer create-project sometimes skips it on case-insensitive filesystems):

ls -la /var/www/magento2/pub/.htaccess
# If missing: download it from the Magento mainline tag matching your version
# and re-place it inside pub/ before reloading Apache.

Step 10 · PHP memory_limit + max_execution_time

Magento’s install path needs at least 2G of PHP memory; the storefront usually runs in 756M–1G. If you are below that, PHP silently crashes mid-render and Apache sends an empty body. The browser shows blank with status 200 in DevTools — the most misleading variant of this bug.

php -i | grep memory_limit
# Expect: memory_limit => 2G => 2G

sudo nano /etc/php/8.3/apache2/php.ini
# memory_limit = 2G
# max_execution_time = 1800
# max_input_time = 1800
# zlib.output_compression = Off
# realpath_cache_size = 10M
# realpath_cache_ttl = 7200

sudo systemctl restart apache2

If you use PHP-FPM, edit /etc/php/8.3/fpm/php.ini instead and restart php8.3-fpm. The Apache one is only consulted in mod_php setups.

Step 11 · Base URL mismatch in core_config_data

If you imported a database from another environment, the stored base URL still points at the old hostname. Magento happily issues a 302 redirect to the old URL and your browser ends up at http://staging.example.com/ instead of http://magento2.local/ — which silently fails to resolve and shows blank.

mysql -u magento -p magento_db -e "
  SELECT path, value FROM core_config_data
  WHERE path IN ('web/unsecure/base_url','web/secure/base_url',
                 'web/unsecure/base_link_url','web/secure/base_link_url');"

mysql -u magento -p magento_db -e "
  UPDATE core_config_data
  SET value = 'http://magento2.local/'
  WHERE path IN ('web/unsecure/base_url','web/secure/base_url',
                 'web/unsecure/base_link_url','web/secure/base_link_url');"

bin/magento cache:flush

Step 12 · Admin-only blank page (2FA, Adobe IMS, custom login)

If only the admin is blank and the storefront works, the cause is almost always one of:

• Two-Factor Auth misconfiguration. Magento 2.4 enables Google/Authy 2FA by default. If the admin email was never delivered or the QR was never scanned, the admin login page can render blank after the first POST. Disable 2FA from the CLI to recover: bin/magento module:disable Magento_TwoFactorAuth Magento_AdminAdobeImsTwoFactorAuth && bin/magento setup:upgrade && bin/magento cache:flush — re-enable and reconfigure once you can log in.
• Adobe IMS module enabled by mistake. Magento 2.4.6+ ships the Adobe IMS admin login modules. On Open Source they redirect to an unreachable Adobe URL and the post-redirect lands blank. Disable with bin/magento module:disable Magento_AdminAdobeIms Magento_AdminAdobeImsTwoFactorAuth.
• Custom admin URL not propagated. If app/etc/env.php has a backend.frontName different from what you are typing in the browser, the URL falls through to the storefront router and 404s blank.

Step 13 · SELinux or AppArmor blocking Apache

On RHEL/CentOS/Alma/Rocky, SELinux can prevent Apache from reading /var/www/magento2/pub or writing to var/. The Apache error log will be silent (SELinux blocks happen before mod_php sees the request) and the browser gets a blank or 403. Check and adjust:

sudo sestatus                                          # enforcing? then check audit log
sudo ausearch -m avc -ts recent | grep magento
sudo chcon -R -t httpd_sys_content_t /var/www/magento2
sudo chcon -R -t httpd_sys_rw_content_t /var/www/magento2/var \
                                       /var/www/magento2/pub/static \
                                       /var/www/magento2/pub/media \
                                       /var/www/magento2/generated

On Ubuntu the equivalent is AppArmor — check /var/log/audit/audit.log or journalctl -k | grep apparmor for blocks against the Apache profile.

Step 14 · OPcache + opcache.validate_timestamps trap

If you redeployed Magento and the blank page started after a deploy, OPcache may still be serving the old compiled bytecode of files that no longer exist. The runtime tries to include a class file OPcache cached, fails, and dies silently.

php -r "opcache_reset();"           # one-shot reset via CLI
sudo systemctl restart php8.3-fpm   # or restart Apache for mod_php

If you rely on file-based deploys (rsync / git pull) on a production box, set opcache.validate_timestamps = 1 with a short revalidate_freq, or wrap every deploy in opcache_reset(). Atomic symlink deploys avoid this entirely — OPcache keys are inode-based, so swapping the symlink misses the cache on purpose.

The diagnosis matrix — pick the right step from one symptom

The 5-minute version — if you only have time for one pass

If you need to unblock fast and read the rest later, run these in order. They cover roughly 80% of real cases:

# 1. Hostname resolves
echo "127.0.0.1 magento2.local" | sudo tee -a /etc/hosts
ping -c 2 magento2.local

# 2. Apache vhost points at pub/ and AllowOverride All (see Step 3)
sudo a2enmod rewrite
sudo apache2ctl configtest && sudo systemctl reload apache2

# 3. Magento in developer mode with errors visible
cd /var/www/magento2
sudo -u www-data bin/magento deploy:mode:set developer
sudo -u www-data bin/magento setup:upgrade
sudo -u www-data bin/magento indexer:reindex
sudo -u www-data bin/magento cache:flush

# 4. Permissions
sudo chown -R www-data:www-data .
sudo chmod -R g+w var generated pub/static pub/media app/etc

# 5. Tail every relevant log and reload the page
tail -f var/log/exception.log var/log/system.log \
        /var/log/apache2/magento2-error.log

If the page is still blank after this, the next request will have printed the real error into one of those three log files — that line tells you which of Steps 8–14 above to jump to.