Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Database Wordpress Data

MySQL Is Running but WordPress Cannot Connect

Trace WordPress connection failure despite running MySQL through sockets, bind address, grants, PHP drivers, DNS and container/network boundaries.

A running MySQL process proves only that the service exists. WordPress still needs the correct listener or socket, hostname resolution, PHP database driver, credentials and user grant from the web server’s network context.

Test from the same environment as PHP. A database client on your laptop or the database host itself follows a different route.

Confirm the listener

Inspect MySQL’s configured bind address, TCP port and Unix socket. Verify the service listens where DB_HOST expects.

Compare:
WordPress DB_HOST
MySQL bind address/port
socket file path
PHP mysqli/PDO availability
web server/container network

Do not expose the database publicly merely to make a test connect.

Test as the web hosting user

Use the host’s terminal or a temporary protected PHP diagnostic to test name resolution and connection. Remove the diagnostic immediately.

Never echo the password or full connection error to visitors. Store a redacted result in a protected log.

CLI PHP may load another configuration or run outside the container used by web PHP; compare both only when relevant.

Distinguish socket and TCP

On many systems, localhost tells MySQL libraries to use a Unix socket, while 127.0.0.1 uses TCP. The socket may live somewhere PHP does not expect or lack accessible permissions.

Use the hosting control panel’s documented DB_HOST. Correct the socket path or PHP configuration rather than creating broad filesystem permissions.

In Docker/container hosting, localhost points to the WordPress container, not the database container.

Verify PHP database extensions

After a PHP version change, mysqli or pdo_mysql may not be enabled for the active handler. PHP logs can show “Call to undefined function mysqli_connect” rather than a WordPress connection message.

Enable the required extension through cPanel, Plesk or the supported package system. Restart/reload only the intended PHP service.

Do not install packages from unofficial repositories on a production server.

Check database grants by host

MySQL accounts include both user and allowed host. user@localhost can differ from user@10.% or another web-node address.

Grant the minimum access to the intended WordPress database from the actual application source. Avoid wildcard remote hosts where a narrower network/user works.

After changing credentials, update WordPress atomically and rotate any exposed password.

Inspect DNS and network policy

For a remote database hostname, resolve it from each web node. Check firewall, security groups and hosting egress/ingress rules on the database port.

DNS may return IPv6 while MySQL listens only on IPv4. Use the platform’s intended record and listener rather than hard-coding a temporary IP indefinitely.

TLS-required database services also need compatible certificates and client settings.

Verify authentication and TLS compatibility

After a MySQL or PHP migration, the database account may use an authentication plugin unsupported by the active client library. Capture the exact “authentication method” or handshake error rather than resetting the user blindly.

For managed remote databases, verify the required CA chain and hostname. Do not disable certificate verification as a permanent workaround. Update the PHP/MySQL client or configure the provider-supported authentication method, then rotate credentials if they were copied through an insecure channel.

Check connection capacity

The service can be running yet return “Too many connections.” Inspect active/sleeping connections and source applications.

Find connection leaks or long-running queries before raising capacity. Increasing the limit without RAM planning can destabilise MySQL.

Use persistent connections only when the host/application design supports their lifecycle.

Repair and prove application access

Correct the listener, socket, extension, grant, DNS or network boundary shown by evidence. Test through WordPress, not only the MySQL client.

Save a controlled draft, update an option and run a scheduled task, then inspect MySQL logs. Recurring care should monitor connection errors from the application network because “service running” is too shallow a health check.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident