WordPress, by default, communicates with external servers for various purposes, checking for plugin/theme updates, fetching remote content, connecting to APIs, and more. But in some cases, like development environments, privacy-focused setups, or debugging.. you may want to disable all outgoing HTTP requests.

One simple line of code can do that:

1
add_filter( 'pre_http_request', '__return_true', 100 );

What Does This Code Do?

This line hooks into the pre_http_request filter and tells WordPress to always return true before making an HTTP request.

This effectively prevents the request from being sent, and WordPress assumes it was handled successfully (even though it wasn’t).

Why Disable HTTP Requests?

Scenarios where this is useful:

  • Local Development: Avoid unnecessary API calls.
  • Debugging: Stop slow external API requests.
  • Privacy/Security: Prevent data from being sent to 3rd-party services.

What Will Break?

Disabling all HTTP requests may break:

  • Plugin/theme updates
  • API integrations (like payment gateways)
  • License or version checks

Use this only if you’re sure of the impact.

Safer Alternatives

Only in Development:

1
if ( defined( 'WP_ENV' ) && WP_ENV === 'development' ) {
2
add_filter( 'pre_http_request', '__return_true', 100 );
3
}

Only for Specific URLs:

1
add_filter( 'pre_http_request', function( $pre, $args, $url ) {
2
if ( strpos( $url, 'example.com' ) !== false ) {
3
return true; // Block this request
4
}
5
return $pre;
6
}, 100, 3 );

Conclusion

Disabling HTTP requests using the pre_http_request filter can be useful in development or security-focused setups. But it should be used with caution, especially in production. Prefer scoped, environment-based, or domain-specific blocking where possible.

Before you add any code snippets to your project, make sure you understand what the code does and back up your files just in case. Even small changes can have big effects, so test everything in a safe environment first!