If you are trying to browse or install plugins in your WordPress dashboard and meet the red error notice:

"An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums."

...you are dealing with a failure in WordPress's ability to communicate with the official WordPress.org API (api.wordpress.org).

While many tutorials suggest editing your /etc/hosts file or changing DNS servers, the root cause is often not a network issue at all, but rather an internal plugin or theme silently intercepting and blocking WordPress’s HTTP requests.

Here is how to diagnose and resolve this issue step-by-step, whether you have terminal (SSH) access or not.

Method 1: The No-Terminal Solution (Plugin Conflict Isolation)

If you do not have SSH access to your server or are uncomfortable using the command line, you can isolate the problem directly from your WordPress admin panel or FTP/File Manager.

In many cases, this error is caused by a security plugin, a "disable updates" utility, or a nulled theme/plugin that installs a script to block WordPress from checking external servers.

Step-by-Step Plugin Isolation:

  1. Deactivate All Plugins:
    • Go to Plugins → Installed Plugins in your dashboard.
    • Select all plugins using the main checkbox.
    • Choose Deactivate from the bulk actions dropdown and click Apply.
    • (If you can't access your admin panel, connect via FTP or cPanel File Manager, navigate to wp-content/, and rename the plugins folder to plugins_old).
  2. Test the Plugin Directory:
    • Go to Plugins → Add New.
    • Check if the directory loads properly now without the error message.
  3. Re-enable Plugins One by One:
    • If the error disappears after deactivating all plugins, one of your plugins is definitely the culprit.
    • Go back to your plugins list and reactivate them one at a time.
    • After activating each plugin, refresh the Add Plugins page to see if the error returns.
  4. Delete the Problematic Plugin:
    • Once you find the specific plugin that triggers the error upon activation, deactivate and delete it.
    • Look for an alternative plugin or contact its developer for support.

Method 2: Advanced CLI & SSH Diagnostics (For Developers & Sysadmins)

If you have SSH access, you can bypass guesswork and identify the exact line of code causing the issue in minutes.

Step 1: Rule Out Network & System SSL Issues

Run a raw cURL command from your terminal to verify if your server can reach WordPress.org over HTTPS:

curl -v https://api.wordpress.org/plugins/info/1.2/
  • Expected Result: An HTTP/2 200 or HTTP/1.1 200 OK response with a valid SSL handshake.
  • If it fails: Fix your system DNS (/etc/resolv.conf or systemd-resolved) or update your CA certificates (sudo apt install --reinstall ca-certificates).

Step 2: Test cURL Inside the PHP Environment

Even if system cURL works, PHP-CLI might have different configurations. Run this code snippet inside PHP:

php << 'EOF'
<?php
$ch = curl_init('https://api.wordpress.org/plugins/info/1.2/');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);

echo "CURL ERROR: " . curl_error($ch) . PHP_EOL;
echo "HTTP CODE: " . curl_getinfo($ch, CURLINFO_HTTP_CODE) . PHP_EOL;
EOF

If this returns HTTP CODE: 200 with no cURL errors, your network, cURL library, and server-level SSL certificates are 100% operational. The issue lies entirely inside WordPress execution.

Step 3: Test WordPress HTTP Transport (wp_remote_post)

WordPress wraps network requests in its own functions. Test how WordPress handles the request internally:

php << 'EOF'
<?php
require_once 'wp-load.php';

$url = 'https://api.wordpress.org/plugins/info/1.2/';
$args = array(
    'timeout' => 15,
    'user-agent' => 'WordPress/' . $GLOBALS['wp_version'] . '; ' . get_bloginfo('url'),
    'body' => array(
        'action' => 'query_plugins',
        'request' => serialize((object)array('browse' => 'featured', 'page' => 1))
    )
);

$response = wp_remote_post($url, $args);

echo "HTTP Code: " . wp_remote_retrieve_response_code($response) . PHP_EOL;
var_dump($response);
EOF

The "Aha!" Moment:

If var_dump($response) returns bool(true) while HTTP Code is completely empty, WordPress is not even sending a request over the network! An internal hook is hijacking the HTTP client and returning a dummy boolean response.

Step 4: Inspect pre_http_request Hooks

WordPress provides a filter named pre_http_request that allows developers to preemptively hijack HTTP calls. Run this script to list all active callbacks attached to this hook:

php << 'EOF'
<?php
require_once 'wp-load.php';

global $wp_filter;
if (isset($wp_filter['pre_http_request'])) {
    foreach ($wp_filter['pre_http_request']->callbacks as $priority => $callbacks) {
        foreach ($callbacks as $name => $details) {
            echo "Priority $priority: $name" . PHP_EOL;
        }
    }
}
EOF

If you see a custom function like block_wp_update_requests or similar overriding functions attached to priority 10, you have found the blocking filter!

Step 5: Locate and Remove the Offending Code

Use grep to scan your wp-content directory for the function name found in Step 4:

grep -rnw '/var/www/your-site/wp-content/' -e 'block_wp_update_requests'

This will reveal the exact file path and line number (e.g., inside a rogue plugin or a theme's functions.php). Delete or deactivate the offending plugin/theme code, reload your dashboard, and the plugin directory will instantly work again!

Summary

When WordPress throws "An unexpected error occurred" on the plugin page:

  1. Don't blindly edit /etc/hosts or server configs.
  2. If you don't have SSH: bulk deactivate all plugins and turn them back on one by one.
  3. If you have SSH: check for internal WordPress hooks like pre_http_request that might be short-circuiting network requests.