How to Fix Cloudflare Error 524 During a WordPress Import

A WordPress import may fail with Cloudflare error 524 when Cloudflare proxying is enabled, even though the same import works after the Cloudflare proxy is disabled.

The error commonly appears while importing:

WooCommerce products
WordPress posts or pages
Customers or users
Large CSV or XML files
Theme demo content
Website backups
Media attachments
Plugin configuration data

Cloudflare error 524 during a WordPress import does not usually mean Cloudflare cannot connect to the website. It means Cloudflare successfully connected to the origin server, but the server did not return an HTTP response before Cloudflare’s timeout was reached.

This guide explains how to complete the import safely, identify the underlying server problem, and prevent the error from returning.

What Does Cloudflare Error 524 Mean?

Cloudflare error 524 means that Cloudflare established a connection with your hosting server, but the server took too long to send an HTTP response.

Cloudflare currently applies a default 120-second Proxy Read Timeout. A 524 error can appear when a request continues processing at the origin without returning a response within that period. Cloudflare also has a separate 30-second Proxy Write Timeout, which cannot be increased.

A WordPress import can easily become a long-running request because the plugin may need to:

Read and validate the uploaded file.
Process thousands of rows.
Download external images.
Create posts, products, terms, and metadata.
Generate image sizes.
Run WooCommerce hooks.
Update lookup tables.
Perform large database queries.

If all of this happens inside one browser request, the process may exceed Cloudflare’s timeout even when PHP is still working correctly in the background.

Cloudflare 524 vs Other Cloudflare Errors

It is important to distinguish error 524 from similar Cloudflare errors.

Error 522: Cloudflare could not establish or maintain the required connection with the origin server.
Error 523: The origin server could not be reached.
Error 524: Cloudflare connected successfully, but the origin took too long to respond.

Therefore, a 524 error usually points to a slow or long-running process at the hosting server rather than a DNS connection failure.

Why WordPress Imports Trigger Error 524

The most common causes include:

A Large Import File

A large CSV, XML, ZIP, or backup file may require more than 120 seconds to process.

Too Many Records Per Batch

Some import plugins process hundreds or thousands of records in one request. A smaller server may not finish that batch quickly enough.

External Image Downloads

Importing images from remote URLs can significantly slow the process. Each image must be downloaded, saved, added to the Media Library, and resized.

Limited PHP Resources

The import may be constrained by:

PHP memory limit
Maximum execution time
Maximum input time
Upload size limit
POST size limit
PHP-FPM timeout
Web-server timeout

Slow Database Operations

Large WooCommerce stores or websites with oversized database tables can make product, metadata, taxonomy, and lookup-table operations take much longer.

Server Resource Exhaustion

High CPU usage, insufficient RAM, disk I/O limitations, or too many simultaneous PHP workers can prevent the server from completing the request quickly.

Cloudflare specifically lists long-running processes, large data queries, and overloaded origin servers as common causes of error 524.

The Fastest Safe Workaround

The fastest workaround is to temporarily bypass Cloudflare while running the import.

Disabling the Cloudflare proxy does not fix a slow server. It removes Cloudflare’s 120-second proxy timeout from the request so the browser can communicate directly with the hosting server.

Before making DNS or proxy changes:

Create a complete website and database backup.
Run the import on staging when possible.
Record the current Cloudflare DNS settings.
Confirm that the origin server has a valid SSL certificate.
Put the site in maintenance mode if the import will change live data.

Solution 1: Temporarily Set the DNS Record to DNS Only

This is usually the most targeted solution because it disables proxying only for the selected hostname.

In Cloudflare:

Log in to the Cloudflare dashboard.
Select your domain.
Open DNS.
Go to Records.
Find the A, AAAA, or CNAME record used by the WordPress website.
Click Edit.
Change Proxy status from Proxied to DNS only.
Save the record.
Allow a few minutes for the change to take effect.
Run the WordPress import again.

A proxied record sends traffic through Cloudflare. A DNS-only record sends visitors directly to the origin server and exposes the actual origin IP address. Cloudflare caching, WAF protection, DDoS protection, and other proxy-level features do not apply while the record is DNS only.

After the import completes:

Return to Cloudflare > DNS > Records.
Edit the same DNS record.
Change DNS only back to Proxied.
Save the record.
Purge the Cloudflare cache if necessary.
Test the frontend and WordPress dashboard.

Do not leave the website DNS-only permanently unless you intentionally want to bypass Cloudflare.

Important SSL Warning

Before disabling proxying, confirm that the hosting server has a publicly trusted SSL certificate for the domain.

A Cloudflare Origin CA certificate is designed for encrypted communication between Cloudflare and the origin. Browsers may not trust it when they connect directly to the server.

If the site shows an SSL certificate warning after disabling the proxy, either:

Install a publicly trusted certificate such as Let’s Encrypt at the origin.
Use a temporary hostname with a valid certificate.
Re-enable proxying and use another import method.

Solution 2: Pause Cloudflare Temporarily

You can also pause Cloudflare for the entire website.

In the Cloudflare dashboard:

Select the domain.
Open Overview.
Find Advanced Actions.
Click Pause Cloudflare on Site.
Confirm the action.
Wait for the change to take effect.
Run the import again.

Cloudflare states that pausing sends traffic directly to the origin server and normally takes five minutes or less. While paused, Cloudflare services such as the WAF, caching, and proxy-level SSL features are unavailable.

After the import, return to the same section and resume Cloudflare.

Changing one DNS record to DNS-only is generally preferable because it affects only that hostname. Pausing Cloudflare affects the whole zone.

Development Mode Will Not Fix Error 524

Cloudflare Development Mode temporarily bypasses cached content, but traffic still passes through Cloudflare’s reverse proxy.

Therefore, Development Mode may help with stale CSS, JavaScript, and page-cache problems, but it does not remove the Proxy Read Timeout responsible for error 524. Cloudflare distinguishes Development Mode from pausing Cloudflare or disabling proxying on a DNS record.

What If the Import Still Fails With Cloudflare Disabled?

This is an important diagnostic result.

If disabling the proxy removes error 524 but produces one of the following errors instead, the underlying problem is at the origin server:

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
Request Timeout
Allowed memory size exhausted
Maximum execution time exceeded
Connection reset
Blank or white screen

In that case, Cloudflare was only displaying the timeout. The hosting server or PHP configuration is the actual cause.

A similar WordPress support case changed from Cloudflare error 524 to a direct 504 timeout after Cloudflare was paused, confirming that the hosting server still could not complete the request.

Solution 3: Reduce the Import Batch Size

Reducing the number of records processed per request is often the best permanent solution.

Look in your import plugin for settings such as:

Records per iteration
Batch size
Products per cycle
Items per request
Processing limit
Import chunk size
AJAX interval

For example, reduce the batch from:

500 records

to:

25 or 50 records

The import may take longer overall, but each individual request is more likely to finish within Cloudflare’s timeout.

For imports involving large images, start with an even smaller batch such as 5 to 20 records.

The ideal value depends on:

Hosting resources
Number of product variations
Number and size of images
Active plugins
Database performance
Complexity of imported metadata

Solution 4: Split the Import File

When the plugin does not offer batch controls, divide the original file into smaller files.

For example, instead of importing one CSV containing 20,000 products, create:

products-01.csv
products-02.csv
products-03.csv
products-04.csv

Each file could contain 1,000 to 5,000 records, depending on server performance.

When splitting the file:

Keep the header row in every CSV.
Preserve the original column order.
Do not break parent and variation relationships.
Avoid importing the same unique ID or SKU twice.
Keep a record of which files have completed.
Test one smaller file before processing the rest.

Do not repeatedly restart a partially completed import without checking the results. Some plugins may create duplicate posts, products, users, or media files.

Solution 5: Increase the WordPress Memory Limit

A large import may exhaust the memory available to WordPress.

Add the following above the line that says /* That's all, stop editing! Happy publishing. */ in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MAX_MEMORY_LIMIT applies to memory-intensive WordPress administration tasks. WordPress documents 256 MB as the normal default administrative limit, although the effective limit also depends on PHP and the hosting environment. Some hosting providers do not allow WordPress to raise the PHP limit automatically.

Increasing the WordPress constant will not help when the hosting account has a lower hard PHP limit. Check the effective value under:

Tools > Site Health > Info > Server

When the value does not change, ask the hosting provider to raise it.

Solution 6: Increase PHP Import Limits

Depending on the hosting platform, update the values using php.ini, .user.ini, the hosting control panel, or the PHP settings interface.

A reasonable starting configuration for a large import is:

memory_limit = 512M
max_execution_time = 600
max_input_time = 600
upload_max_filesize = 512M
post_max_size = 512M

Adjust the upload and POST limits to match the actual import file.

Keep these rules in mind:

post_max_size should be equal to or greater than upload_max_filesize.
The hosting provider may enforce lower account-level limits.
Increasing PHP execution time does not increase Cloudflare’s standard proxy timeout.
The direct request must also be allowed to run long enough by Nginx, Apache, or PHP-FPM.
Extremely high limits can hide inefficient plugin or database behaviour.

Increasing PHP execution time alone will not fix a proxied request that continues beyond Cloudflare’s 120-second timeout. You must also reduce the request duration, bypass the proxy temporarily, or move the operation to a background process.

Solution 7: Check Nginx, Apache, and PHP-FPM Timeouts

On a managed host, ask support to check:

PHP-FPM request timeout
Nginx fastcgi_read_timeout
Nginx proxy_read_timeout
Apache Timeout
Load-balancer timeout
Database query timeout
Hosting-panel process limits

A possible Nginx configuration might include:

fastcgi_read_timeout 600;

A reverse-proxy configuration may use:

proxy_read_timeout 600;

These examples must be placed in the correct server block and tested before deployment. On shared or managed hosting, only the hosting provider may be able to change them.

Remember that raising an origin timeout does not override Cloudflare’s standard 120-second Proxy Read Timeout.

Solution 8: Import Without Downloading Images

External media downloads are frequently the slowest part of a product or content import.

When the plugin supports it:

Import posts or products without images.
Complete the database import first.
Import or regenerate media in a separate operation.
Use smaller batches for media processing.

Also check whether external image URLs:

Are publicly accessible
Redirect repeatedly
Require authentication
Block your server IP
Return very large files
Use expired SSL certificates
Are rate-limited

A single slow image host can delay an entire import batch.

Solution 9: Use WP-CLI or a Background Import

The most reliable solution for very large imports is to avoid one long browser request.

Check whether the plugin provides:

WP-CLI commands
Cron-based processing
Queue processing
Background AJAX batches
Server-side import commands
Scheduled imports

A command-line import is not routed through the visitor-facing Cloudflare proxy, so it is not subject to the same browser request timeout.

The exact command depends on the plugin. Do not assume a generic WP-CLI command exists. Check the plugin’s official documentation or contact its developer.

Solution 10: Use a DNS-Only Import Subdomain

For repeated large imports, consider creating a dedicated administration or import hostname, such as:

import.example.com

Configure it as DNS-only and restrict access using:

HTTP authentication
VPN access
An IP allowlist
Hosting firewall rules
A private staging environment

Cloudflare recommends moving regularly long-running HTTP processes behind a DNS-only subdomain when those processes normally exceed the proxy timeout.

This is an advanced configuration. The hostname must point to the correct WordPress installation, use a valid SSL certificate, and be restricted so it does not create an unsecured alternative route to the website.

Enable WordPress Debug Logging

When the import still fails, temporarily enable WordPress logging.

Add this to wp-config.php before the final stop-editing line:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

@ini_set( 'display_errors', 0 );

Run the import once, then inspect:

/wp-content/debug.log

Look for errors such as:

Allowed memory size exhausted
Maximum execution time exceeded
MySQL server has gone away
cURL error
Uncaught TypeError
Fatal error

WordPress recommends taking a backup or using staging before enabling debugging. It also recommends hiding errors from visitors while logging them to wp-content/debug.log. Debugging should be disabled after troubleshooting, particularly on a production website.

After testing, change the settings back:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Delete or protect the debug log because it may contain sensitive filesystem paths, URLs, queries, or plugin information.

Check the Hosting Logs

The Cloudflare error page should display:

The date and time
The requested hostname
A Cloudflare Ray ID
The Cloudflare data centre

Record this information and provide it to the hosting provider.

Ask the host to inspect:

Web-server access logs
Web-server error logs
PHP error logs
PHP-FPM slow logs
MySQL slow-query logs
CPU and memory usage
Disk I/O
PHP worker availability
Process termination records

The exact timestamp and requested import URL will help the hosting provider locate the failing request.

Can the Cloudflare Timeout Be Increased?

Cloudflare Enterprise customers can increase the Proxy Read Timeout up to 6,000 seconds through supported zone settings or applicable Cache Rules.

However, the Proxy Write Timeout is separate and cannot be adjusted.

For most WordPress websites using Free, Pro, or Business plans, the practical solution is to:

Make each import batch finish within 120 seconds.
Temporarily use DNS-only mode.
Use WP-CLI or a background process.
Optimize the origin server.

Upgrading Cloudflare solely to run occasional WordPress imports is usually unnecessary.

Recommended WordPress Import Workflow

Use the following process for the safest result:

Create a full database and file backup.
Test the import on staging.
Update WordPress and the import plugin.
Remove unnecessary duplicate caching or import plugins.
Reduce the import batch size.
Raise PHP and WordPress memory limits when necessary.
Temporarily change the Cloudflare record to DNS-only.
Run one small test import.
Confirm that posts, products, images, and metadata are correct.
Run the remaining files or batches.
Check for duplicate records.
Restore Cloudflare proxying.
Purge relevant caches.
Verify the frontend and WordPress dashboard.
Disable debugging and remove temporary files.

Frequently Asked Questions

Is Cloudflare blocking the WordPress import?

Not necessarily. A 524 response means Cloudflare connected to the origin, but the origin did not respond before the proxy timeout. The import process may simply be too slow.

Will increasing `max_execution_time` fix error 524?

It may prevent PHP from stopping the import, but it will not extend Cloudflare’s standard 120-second proxy timeout. The request must finish sooner, run directly against the origin, or be processed in the background.

Should I permanently disable the Cloudflare proxy?

No. Use DNS-only mode temporarily for troubleshooting or imports, then restore proxying so the website regains Cloudflare caching, WAF, DDoS protection, and related features.

Why do I receive a 504 error after disabling Cloudflare?

This indicates that the origin server or another upstream service is also timing out. Cloudflare was not the root cause. Check PHP, Nginx, Apache, PHP-FPM, database performance, and hosting resources.

Can the import continue after the browser shows error 524?

Sometimes. The PHP process may continue after the browser connection closes, depending on the plugin and server configuration. Check the import history, database records, and logs before starting it again.

Does Cloudflare Development Mode prevent 524 errors?

No. Development Mode bypasses Cloudflare caching but does not bypass the reverse proxy or its request timeout.

Final Solution

Cloudflare error 524 during a WordPress import occurs because Cloudflare connects successfully to the origin server, but the import request takes longer than the permitted proxy timeout.

The quickest workaround is to temporarily set the relevant DNS record to DNS only, complete the import, and then restore Cloudflare proxying.

For a permanent solution:

Reduce the import batch size.
Split large files.
Increase appropriate PHP and server limits.
Process images separately.
Optimize slow database operations.
Use WP-CLI or background processing for large imports.
Check server logs for resource or timeout errors.

Do not treat disabling Cloudflare as the complete fix. If the import also fails when connected directly to the origin, the hosting server, PHP configuration, database, or import plugin still needs to be optimized.