Fix ERR_INVALID_RESPONSE in phpMyAdmin and PHP

What does ERR_INVALID_RESPONSE mean in phpMyAdmin and PHP?

ERR_INVALID_RESPONSE tells you that the browser could not process the server response normally; it does not tell you which server component caused it. Seeing the message on a phpMyAdmin page does not automatically make phpMyAdmin or MySQL the culprit.

One administrator may see phpMyAdmin open normally, then fail only after clicking Import. Another may get ERR_INVALID_RESPONSE on every .php URL while static HTML continues to work. A third may notice that the failure happens only after a long SQL query. The browser message is the same. The server-side diagnosis is not.

Before touching the configuration, record the exact URL, the action that triggers the error, how long the request runs before it fails, whether a simple PHP file fails too, and whether static HTML works. Those five observations can eliminate half of the wrong theories before you edit a single setting.

Does the error affect only phpMyAdmin or every PHP script?

A phpMyAdmin error page is a poor reason to reinstall phpMyAdmin if you have not yet proved that PHP itself works. If a minimal PHP script produces the same ERR_INVALID_RESPONSE, start below the application layer.

Test from the simplest response to the most complex:

1. Request a known static HTML file.
2. Request a minimal PHP script.
3. Keep that PHP script independent of MySQL.
4. Open phpMyAdmin.
5. If phpMyAdmin loads, reproduce the specific failing action: login, table browse, SQL query, import, or export.

A temporary PHP diagnostic endpoint does not need to expose the entire phpinfo() output:

<?php
header('Content-Type: text/plain; charset=UTF-8');

echo 'PHP_VERSION=' . PHP_VERSION . PHP_EOL;
echo 'PHP_SAPI=' . PHP_SAPI . PHP_EOL;
echo 'memory_limit=' . ini_get('memory_limit') . PHP_EOL;
echo 'max_execution_time=' . ini_get('max_execution_time') . PHP_EOL;
echo 'max_input_time=' . ini_get('max_input_time') . PHP_EOL;
echo 'post_max_size=' . ini_get('post_max_size') . PHP_EOL;
echo 'upload_max_filesize=' . ini_get('upload_max_filesize') . PHP_EOL;
echo 'upload_tmp_dir=' . ini_get('upload_tmp_dir') . PHP_EOL;
echo 'session.save_path=' . ini_get('session.save_path') . PHP_EOL;

Remove the file when the test is finished. Leaving diagnostic pages publicly accessible creates information exposure for no diagnostic benefit.

Do not use php -v in SSH as proof that the website's PHP stack is healthy. CLI PHP and PHP-FPM can use different versions, INI files, extensions, environment settings, and limits. A healthy CLI binary proves only that CLI PHP starts.

How do you inspect the HTTP response that Chrome rejects?

Start outside the browser. curl can show whether the server returns an HTTP status, headers, TLS errors, redirects, or a connection failure before a usable response is complete.

Use TLS verification normally for the first request:

curl -v https://example.com/phpmyadmin/

If this fails with a certificate verification error, do not immediately hide that fact with -k. The certificate chain or hostname may itself need attention. If curl cannot resolve the hostname at all, troubleshoot DNS resolution before moving deeper into PHP-FPM. For a controlled comparison only, -k can tell you whether skipping certificate verification changes the request:

curl -vk https://example.com/phpmyadmin/

Make sure curl is testing the same request that fails in the browser

This is where a seemingly good diagnosis often goes wrong. phpMyAdmin may fail on an authenticated POST or AJAX request, while a plain curl command requests the login page with GET and receives a perfectly valid 200. Those are not equivalent tests.

If the failure happens on a particular request, inspect it in Chrome DevTools under Network. Check:

• the exact URL;
• GET versus POST;
• request payload;
• redirects;
• cookies and authentication state;
• the point at which the request stalls or fails.

For a difficult case, DevTools can copy the browser request as a curl command. That reproduces headers, cookies, and the request method much more closely than typing the URL manually.

For a simple GET request, forcing HTTP/1.1 is a useful comparison:

curl -v --http1.1 https://example.com/phpmyadmin/

To print headers while discarding the response body:

curl -sS -D - -o /dev/null https://example.com/phpmyadmin/

To record status and total duration:

curl -sS -o /dev/null \
  -w 'http=%{http_code} time=%{time_total}\n' \
  https://example.com/phpmyadmin/

Do not rely only on curl -I. It sends a HEAD request, and an application or proxy may handle HEAD differently from the GET or POST request that actually fails.

If an equivalent curl request fails along with Chrome, move toward the server logs. If curl succeeds, first verify that it really reproduced the same authenticated request before concluding that the problem exists only in the browser path.

Which Nginx, Apache, and PHP-FPM logs should you check?

Reproduce one failed request and read the messages written at the same timestamp. That is more reliable than scrolling through a large error log and collecting every alarming line you can find.

Common clues include PHP memory exhaustion, a PHP-FPM child exiting, an upstream timeout, an upstream connection closing early, permission errors, full filesystems, and kernel OOM events.

The exact wording varies between PHP, Nginx, operating-system, and package versions, but representative fragments can look like this:

PHP Fatal error: Allowed memory size of ... bytes exhausted ...

upstream prematurely closed FastCGI stdout while reading response header from upstream

WARNING: [pool ...] child ... exited on signal ...

Out of memory: Killed process ... (php-fpm) ...

Do not search only for exact full strings. Process IDs, filenames, pool names, and surrounding wording change. Match the type of event to the request timestamp.

Typical commands on a VPS include:

tail -f /path/to/nginx/error.log
tail -f /path/to/apache/error.log
journalctl -u <php-fpm-service> --since "-10 min"
journalctl --since "-10 min"

Log paths vary between distributions, hosting panels, virtual hosts, and PHP-FPM pools. Determine the actual configuration on the server instead of assuming a universal /var/log/... path.

Use access-log timing when it is available

An access log can add a second piece of evidence. Depending on the Nginx or Apache log format, it may contain the final HTTP status, request duration, or upstream response time. If a request that normally completes in 0.2 seconds suddenly spends 60 seconds waiting on FastCGI before failing, that narrows the problem considerably.

Not every server logs those timing fields by default, so do not assume they exist. If they are already present, use them. There is no need to redesign production logging in the middle of a simple incident.

Keep PHP errors in server logs on production systems rather than turning the browser into a PHP error console with permanent display_errors.

Is PHP-FPM crashing, saturated, or terminating the request?

Static assets load, Nginx is alive, but every dynamic page stalls or dies. In that situation PHP-FPM may be down, a worker may be crashing, or the pool may simply have no free workers. These cases look similar from the browser but require different fixes.

First identify the actual service and processes:

systemctl --type=service | grep -Ei 'php.*fpm'
ps aux | grep '[p]hp-fpm'

Then watch the service while reproducing the failure:

systemctl status <php-fpm-service>
journalctl -u <php-fpm-service> --since "-15 min"

A worker exits or receives a signal

Look for a child that exits unexpectedly, a signal, segmentation fault, or repeated worker replacement at the same time as the request. Native PHP extensions can crash a worker without producing an ordinary PHP exception. If the system captures core dumps, coredumpctl can help confirm that a real process crash occurred.

A representative journal fragment may contain wording similar to:

WARNING: [pool www] child 12345 exited on signal 11 (SIGSEGV) ...

The exact message varies, but the key evidence is that a worker dies when the failing request runs.

PHP-FPM is alive but the pool has no free workers

A running master process can still serve nothing promptly. If all workers are busy and the pool reaches pm.max_children, new requests wait for an available process. Eventually Nginx, Apache, or another proxy may time out while PHP-FPM itself remains technically “running.”

Search the PHP-FPM log for messages about reaching pm.max_children. If the FPM status page was already configured securely, useful fields include:

• listen queue;
• idle processes;
• active processes;
• max active processes;
• max children reached;
• slow requests.

Do not expose a PHP-FPM status page publicly just to diagnose one incident. If it already exists, keep access restricted.

Use the PHP-FPM slowlog for requests that do not crash

A request can be slow enough to cause an upstream timeout without ever crashing PHP. For that case, PHP-FPM supports request_slowlog_timeout and slowlog. When configured, PHP-FPM can dump a PHP backtrace for requests that exceed the slow-request threshold.

request_slowlog_timeout = 5s
slowlog = /path/to/php-fpm-slow.log

Those values are examples, not universal recommendations. On an existing production pool, inspect the current configuration first. The slowlog is useful because it can show whether the worker is stuck in application code, a database call, filesystem access, or another slow operation.

request_terminate_timeout is different: it can terminate a worker that spends too long servicing one request. If the browser error appears after nearly the same interval and the FPM journal shows termination at that point, you have a much stronger diagnosis than “PHP is slow.”

Is PHP memory or VPS RAM running out?

PHP memory_limit and system-wide memory exhaustion are different failures. Both can interrupt a PHP response, but changing one does not repair the other.

How to distinguish PHP memory_limit from the OOM killer

When PHP itself reaches its configured memory ceiling, the PHP log usually contains a fatal error similar to:

PHP Fatal error: Allowed memory size of ... bytes exhausted ...

If Linux runs out of memory and kills a process, look in the kernel log instead:

free -h
ps aux --sort=-%mem | head
journalctl -k --since "-30 min" | grep -Ei 'oom|out of memory|killed process'
dmesg -T | grep -Ei 'oom|out of memory|killed process'

Why raising memory_limit can make a small VPS less stable

Imagine a PHP-FPM pool with several simultaneous workers. Raising each worker's possible ceiling from 128M to 512M creates no new RAM. It only lets each script consume more before PHP stops it. If MySQL and other workers are already using most of the server memory, the result can shift from one controlled PHP fatal error to system-wide memory pressure.

There is no universally correct memory_limit. Look at total RAM, real worker consumption, concurrency, MySQL usage, and the workload that triggers the problem.

free -h can look healthy while one service still hits a memory limit

On containers and some systemd-managed services, the process may be constrained by a cgroup or container memory limit that is lower than the host's available RAM. In that case free -h alone can be misleading: the machine has memory, but the PHP-FPM service is not allowed to use all of it.

If the kernel or service logs show an OOM event while host-level RAM still looks comfortable, inspect the container or cgroup memory controls before increasing PHP limits.

PHP fatal in the PHP log points toward the PHP limit and workload. A killed process in the kernel log points toward system or service-level memory pressure. Do not treat both as the same “out of memory” problem.

Is a PHP, PHP-FPM, Nginx, or Apache timeout cutting the request off?

Repeated failure after nearly the same amount of time is one of the clearest timeout clues. Record the duration before changing the configuration. If Chrome reports ERR_CONNECTION_TIMED_OUT instead, treat it as a separate connection-timeout symptom rather than assuming it is the same failure.

Measure the failure interval first

Run the same operation two or three times. If an import repeatedly stops around one minute while other requests complete normally, compare that interval with the active limits in PHP, PHP-FPM, Nginx, Apache, and any proxy in front of them.

curl -sS -o /dev/null \
  -w 'http=%{http_code} time=%{time_total}\n' \
  https://example.com/problem-url

The often-seen values of 60, 120, or 300 seconds are not universal defaults for the whole stack. A matching number is a clue only after you confirm the corresponding configuration or log entry.

Nginx's fastcgi_read_timeout deserves special care. It is not simply “the maximum PHP page duration.” It limits the interval between successive reads from the FastCGI upstream. A backend that periodically returns data can behave differently from one that stays silent during a long operation.

Why increasing max_execution_time may do nothing

Suppose PHP allows a script to run for five minutes, but PHP-FPM terminates it sooner. Or PHP-FPM waits, but Nginx stops waiting for FastCGI data first. Raising max_execution_time cannot override a shorter limit in another component.

The reverse also applies: a larger Nginx or Apache timeout cannot rescue a script PHP has already terminated.

For Apache, do not blindly copy one timeout directive from an Nginx example. The relevant setting depends on how Apache connects to PHP, including whether a FastCGI/proxy module is involved. Inspect the actual virtual-host and module configuration.

Why does ERR_INVALID_RESPONSE appear during phpMyAdmin imports or exports?

A common case is very specific: phpMyAdmin opens quickly, browsing small tables works, a small SQL dump imports successfully, but a large import dies. That pattern points toward the heavy request path, not toward a completely broken phpMyAdmin installation.

A large import passes through several separate stages:

1. The web server accepts the request body.
2. PHP parses the incoming POST data.
3. PHP stores the uploaded file in a temporary location.
4. phpMyAdmin reads and processes the dump.
5. MySQL executes the statements.
6. PHP and the web server return the final response.

A limit at any one of those stages can end the operation.

Does the request reach PHP at all?

Before raising PHP settings, determine whether PHP sees the request. A web server or proxy may reject an oversized request before PHP-FPM receives it. In that case changing post_max_size has no effect because the request never reaches PHP.

Check the access/error logs around the upload timestamp and the PHP-FPM log. A web-server-side request-size error with no corresponding PHP processing is a different problem from a PHP upload that begins and fails later.

Does PHP accept and store the uploaded file?

Check these effective web PHP settings:

upload_max_filesize
post_max_size
max_input_time
memory_limit
max_execution_time
upload_tmp_dir

post_max_size must allow the complete POST request, not just the raw SQL file. It should therefore be larger than the intended upload_max_filesize.

max_input_time matters earlier than max_execution_time: it limits the time PHP can spend parsing incoming request data before normal script execution begins. On a slow upload or very large POST, that distinction matters.

upload_tmp_dir identifies the directory PHP uses for uploaded temporary files when configured. It must be writable by the PHP service user. If no custom directory is configured, PHP may use the system temporary location instead.

Check free space and inodes as well:

df -h
df -i

Does phpMyAdmin fail after PHP has accepted the upload?

phpMyAdmin has its own relevant configuration, including:

$cfg['ExecTimeLimit']
$cfg['MemoryLimit']
$cfg['TempDir']

Those settings do not override stricter PHP-FPM, web-server, or proxy limits. A large ExecTimeLimit does not help if Nginx stops waiting first, and a large phpMyAdmin memory setting cannot create RAM that the VPS does not have.

Compare a known small dump with the dump that fails. Note whether the browser fails during upload, immediately after upload, or only after MySQL has been busy for some time. That timing separates request-size problems from execution problems surprisingly well.

Can MySQL reject one large statement inside an otherwise valid dump?

Yes, but do not make MySQL's max_allowed_packet the default explanation for ERR_INVALID_RESPONSE. Check it only when the database error points there, for example when a dump contains a very large INSERT, BLOB, or packet and MySQL reports a packet-size-related failure.

If the PHP and phpMyAdmin logs show normal processing until a particular SQL statement reaches MySQL, inspect the database error rather than blindly raising every web limit.

When should a large dump be imported without phpMyAdmin?

For a large restore, the MySQL command-line client removes the browser upload, PHP POST parsing, and phpMyAdmin request lifetime from the import path:

mysql -u database_user -p database_name < backup.sql

It does not remove MySQL limits, disk pressure, locks, or server resource constraints. It simply avoids several web-specific limits. Use this method when shell access is available and the database credentials are known.

If small phpMyAdmin operations also fail, switching to CLI is a workaround for the import, not a fix for the broken web application.

Can TempDir, PHP sessions, or permissions break phpMyAdmin?

After a server migration or PHP-FPM user change, phpMyAdmin may load partly, lose sessions, fail during import, or return permissions-related errors while MySQL itself remains perfectly healthy. Temporary storage and session paths deserve their own check.

Start with the filesystem:

df -h
df -i

A server can have free disk space but no free inodes. In that state PHP may be unable to create a session or temporary file even though df -h looks comfortable.

For a known path, inspect the whole directory chain:

namei -l /path/to/tmp
ls -ld /path/to/tmp

The PHP-FPM service user must be able to traverse parent directories and perform the required operation in the final directory. Do not assume the process always runs as www-data; hosting panels and separate PHP-FPM pools frequently use another account.

Check both PHP and phpMyAdmin session paths

A CLI check can provide a clue:

php -i | grep session.save_path

But CLI PHP may use a different INI file from the FPM worker serving phpMyAdmin. Confirm the effective web value before changing the filesystem.

phpMyAdmin can also define:

$cfg['SessionSavePath']

If it is set, verify that the directory exists, is writable by the actual service user, and is not publicly exposed through the web server.

For phpMyAdmin temporary files, inspect:

$cfg['TempDir']

Keep permissions as narrow as the deployment allows. phpMyAdmin needs a usable directory, not a world-writable directory by default.

What if Unix permissions look correct but access is still denied?

owner, group, and mode bits are not the only access controls on every Linux system. open_basedir can prevent PHP from reaching a path even when the filesystem permissions are valid. SELinux or AppArmor can also deny access on systems where those controls are active.

If the error log still reports Permission denied after the service user and Unix permissions have been checked, look at those additional controls before opening the directory further.

After correcting the path, rerun the exact phpMyAdmin action that failed. A successful manual write test is useful, but the real confirmation is that phpMyAdmin can complete the original session, import, or export operation.

When should you investigate malformed headers or response compression?

Move to response-format and compression tests only after more common causes such as PHP-FPM termination, OOM, permissions, and timeouts have been excluded. ERR_INVALID_RESPONSE is not a synonym for “gzip problem,” and compression should not become the default suspect without supporting evidence.

This branch makes sense when you have clues such as:

• Nginx or another proxy reports an invalid upstream/FastCGI header;
• a custom PHP application manipulates response headers;
• the request behaves differently over HTTP/1.1 and another negotiated protocol;
• the problem appeared after adding a reverse proxy or another response-processing layer;
• a compression or decoding error is visible separately in the browser, server log, or curl output.

Compare a normal request with HTTP/1.1:

curl -v https://example.com/problem-url
curl -v --http1.1 https://example.com/problem-url

Then, only if compression is genuinely part of the investigation, compare compressed response handling:

curl -v --compressed https://example.com/problem-url

To save the response body while printing headers:

curl -sS -D - -o /tmp/body https://example.com/problem-url

Custom PHP applications deserve more suspicion than stock phpMyAdmin here. Code may send malformed headers, generate output at the wrong stage, or combine application-level compression with another transformation in the web-server or proxy layer.

If changing HTTP protocol or compression changes the behavior, treat that as a lead, not proof. Compare the server logs and the request path before permanently disabling compression or changing protocol settings.

The practical question is simple: did PHP produce a valid response and did a later server/proxy layer alter it, or was the FastCGI response already broken before that point?

Is MySQL responsible when the error appears in phpMyAdmin?

The browser fails on a database administration page, so MySQL often gets blamed first. That shortcut is unreliable. MySQL becomes a strong suspect only when the failure correlates with database access or a specific SQL operation.

If a PHP endpoint that does not connect to MySQL also fails, return to PHP-FPM, FastCGI, memory, and the web server. There is little value in tuning InnoDB while database-independent PHP responses are already broken.

When the problem is DB-dependent, check server availability:

mysqladmin ping

One useful detail: an Access denied response from mysqladmin ping still proves that the MySQL server answered. Authentication failed, but the daemon is not simply unreachable or stopped.

Check the actual database service installed on the machine:

systemctl status mysql
systemctl status mariadb

Do not expect both service names to exist. If a later check depends on version-specific behavior, verify the installed MySQL version before applying version-dependent configuration advice.

For a query that appears to hang phpMyAdmin, inspect active database work:

SHOW PROCESSLIST;
SHOW FULL PROCESSLIST;

Look for long-running statements, locks, a large result, connection pressure, or a server restart around the same timestamp. If the slow query log is already enabled, correlate it with the failed request rather than reading unrelated historic entries.

A long query may be the trigger, but do not jump directly to indexes, innodb_buffer_pool_size, or general MySQL tuning until the database evidence points there. Fix the failing layer, not the product whose logo happens to be on the page.

Can a reverse proxy, CDN, or WAF be the failing layer?

If the same application response works from the origin but fails through the public path, the intermediate HTTP layer deserves attention. That layer may be Nginx in front of Apache, a load balancer, CDN, WAF, hosting proxy, or another gateway.

When the origin IP is known and direct HTTPS access is allowed, preserve the hostname and TLS SNI with --resolve:

curl --resolve example.com:443:ORIGIN_IP \
  https://example.com/problem-url

This is preferable to requesting https://ORIGIN_IP/, which may select the wrong virtual host and cause certificate-hostname problems unrelated to the application.

Compare:

1. the normal request through the public hostname;
2. the same hostname sent directly to the origin;
3. the same HTTP method, authentication state, and request body where practical.

The third point matters. A public authenticated POST that fails cannot be meaningfully compared with an unauthenticated GET to the origin login page.

If the equivalent origin request works repeatedly while the public path fails, investigate upstream timeout, buffering, protocol handling, WAF rules, response transformation, or provider-specific limits. If both paths fail, the origin remains part of the problem.

Some origins accept traffic only from proxy networks or are intentionally blocked from direct Internet access. Do not weaken a firewall or bypass a security design just to perform this test.

Which fix should you apply after finding the cause?

Change the component for which you have evidence. ERR_INVALID_RESPONSE has no universal PHP setting because it can be the final browser symptom of several unrelated failures.

Change one variable and rerun the failing scenario. If that change does not alter the result, revert it or document why it stays. This is slower than editing five limits in one shot, but it leaves you with an actual diagnosis instead of a lucky configuration.

How do you verify that ERR_INVALID_RESPONSE is really fixed?

The original failing operation must work repeatedly without creating a new server-side error. One successful page load after restarting PHP-FPM is not enough.

Keep a few measurements from the successful control run: HTTP status, total duration, relevant log timestamp, and memory/process state. If the problem returns, those values provide a baseline instead of forcing you to start from memory.

If phpMyAdmin works only immediately after a PHP-FPM restart and degrades again under the same request, the restart restored service state. It did not remove the cause. Check worker saturation, slow requests, memory growth, crashes, and the resource that changes between the healthy and failed states.

The fix should survive the request that used to break it.

What should you send to hosting support or a server administrator?

A ticket saying “phpMyAdmin shows ERR_INVALID_RESPONSE” gives the administrator very little to correlate with server logs. A timestamp, exact request, reproducibility pattern, and a few completed checks are far more useful. On shared hosting, where customers normally do not have root access to PHP-FPM and system logs, the provider may need to correlate that timestamp with server-side events.

Include:

1. The exact URL where ERR_INVALID_RESPONSE appears.
2. The exact failure time and time zone.
3. A screenshot of the browser error.
4. The action immediately before the failure.
5. Whether static HTML works.
6. Whether a minimal PHP endpoint works.
7. Whether the failure is constant or intermittent.
8. Approximately how long the request runs before failing.
9. The curl result if you can reproduce an equivalent request safely.
10. The SQL dump size if the problem is an import.
11. Any visible PHP, phpMyAdmin, MySQL, or web-server error text.

If you have root access to the VPS, attach only the relevant log window around the failure:

• Nginx or Apache error log;
• PHP-FPM journal;
• PHP-FPM slowlog if the request was captured there;
• kernel OOM messages when memory pressure is suspected;
• MySQL or MariaDB log when the database branch has evidence.

If you copied a request from DevTools as curl, remove session cookies, CSRF tokens, Authorization headers, and other secrets before sending it anywhere outside a trusted support channel.

Do not send a MySQL password, phpMyAdmin password, private key, or API token just to diagnose this browser error.

A useful support request should make four facts obvious: what failed, when it failed, which request triggered it, and which server layers have already been excluded. Once those are known, ERR_INVALID_RESPONSE stops being a vague Chrome message and becomes a specific server-side investigation.