Title: Duplicator version update breaks it
Last modified: September 11, 2026

---

# Duplicator version update breaks it

 *  [michaelmossey](https://wordpress.org/support/users/michaelmossey/)
 * (@michaelmossey)
 * [7 hours, 59 minutes ago](https://wordpress.org/support/topic/duplicator-version-update-breaks-it/)
 * Backups are failing after updating Duplicator version. Problem is that it can’t
   reach the AJAX endpoint (loopback) and local control is failing. (Backups hang.)
   I disabled all other plugins including security. I deactivated Cloudflare DNS.
   I tried all debugging steps in the knowledge base. Please fix quickly, this is
   messing up my deadlines.
 * The page I need help with: _[[log in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fduplicator-version-update-breaks-it%2F%3Foutput_format%3Dmd&locale=en_US)
   to see the link]_

Viewing 3 replies - 1 through 3 (of 3 total)

 *  Thread Starter [michaelmossey](https://wordpress.org/support/users/michaelmossey/)
 * (@michaelmossey)
 * [6 hours, 50 minutes ago](https://wordpress.org/support/topic/duplicator-version-update-breaks-it/#post-19017184)
 * By the way I have Dreamhost and they did something to verify the loopback was
   working:
 * To check the current state, I ran a live test against the exact endpoint
   Duplicator
   uses:curl -s -o /dev/null -w “HTTP %{http_code}\n”“[https://www.learnwithmikemossey.com/wp-admin/admin-ajax.php?action=duplicator_process_worker&duplicator_kprobe=test](https://www.learnwithmikemossey.com/wp-admin/admin-ajax.php?action=duplicator_process_worker&duplicator_kprobe=test)“
   HTTP 200That 200 response means the loopback endpoint is responding correctlyright
   now.
 *  Thread Starter [michaelmossey](https://wordpress.org/support/users/michaelmossey/)
 * (@michaelmossey)
 * [13 minutes ago](https://wordpress.org/support/topic/duplicator-version-update-breaks-it/#post-19017494)
 * Here’s more information from tech support at Dreamhost: (note that I tested with
   all other plugins disabled)
 *     ```wp-block-code
       WordPress 7.1PHP 8.3.30Duplicator 5.0.2I also checked the previous Duplicator logs and confirmed that you werealready using DupArchive, so there is no need to switch the archiveengine.ARCHIVE Type=DUP Mode=DupArchiveI then tested the same admin ajax endpoint that Duplicator uses for itsloopback request.The direct request completed successfully.AJAX_HTTP=200TTFB=1.805659sTOTAL=1.805945sAJAX_BODY=okThe same test performed through the WordPress HTTP API also completedsuccessfully.WP_LOOPBACK=PASSHTTP=200TIME=1.683sBYTES=2I also checked the PHP FastCGI processes during the test. Only one PHPprocess was active at that time.PHP_PROCESS_COUNT=1To test whether several loopback requests would exhaust the available PHPprocesses, I sent three requests at the same time.All three returned HTTP 200.REQ=1 HTTP=200 TOTAL=1.815026sREQ=3 HTTP=200 TOTAL=5.287642sREQ=2 HTTP=200 TOTAL=5.525003sI also reviewed the recent logs for FastCGI errors, ModSecurity blocks,and HTTP 500, 502, 503, and 504 responses during this test.No matching errors were found.RECENT DUPLICATOR 500 AND 503 ACCESS EVENTSNo matching entriesFASTCGI MODSEC AND SERVER ERROR EVIDENCENo matching entriesThere was an earlier FastCGI process exhaustion event in the server logs,so that condition did occur previously.mod_fcgid: cannot apply process slot for /dh/cgi-system/php83.cgiAt that time, the server was unable to start another PHP process until anexisting process became available.However, the new testing does not reproduce that condition, and we do notcurrently have evidence showing that DupArchive itself caused the FastCGIexhaustion before the backup started.The most useful finding came directly from the current Duplicator tracelog.Duplicator recorded the following message several times during itskickoff test.KICKOFF TEST: probe rejectedno pending probe or code mismatchThe messages were recorded repeatedly at 01:42 on September 11.01:42:02 probe rejected01:42:05 probe rejected01:42:07 probe rejected01:42:11 probe rejectedThis means that the request is reaching the Duplicator code, butDuplicator is rejecting its own kickoff probe because there is no pendingprobe or because the probe code does not match what it expects.I also found earlier failed Duplicator builds where Duplicator itselfeventually cancelled the process.Package 22 has been going for 90.082505683104 minutes so cancellingRUNTIME ERRORBackup creation failedConclusion.The current tests show that the DreamHost server can successfully processthe Duplicator admin ajax loopback request.The endpoint currently returns HTTP 200, WordPress can reach the sameendpoint, several simultaneous requests also complete, and the PHPprocess pool was not exhausted during our testing.There is also no current evidence of a ModSecurity block or FastCGI errorduring these tests.The earlier FastCGI exhaustion was a real event, but the current evidencedoes not confirm that Duplicator archive creation caused it.The strongest current evidence is the Duplicator 5.0.2 trace messagestating that the kickoff probe was rejected because there was no pendingprobe or there was a code mismatch.Because of this, the current issue appears more closely related to theDuplicator kickoff process itself, or a possible interaction betweenDuplicator and another WordPress plugin, rather than a persistent serverblock.Since you mentioned that other users are reporting similar behavior afterDuplicator version 5 was released, I recommend providing the Duplicatorsupport team with the exact trace message below.Duplicator 5.0.2WordPress 7.1PHP 8.3.30ClientSideKick.phpconfirmLoopbackProbeKICKOFF TEST: probe rejectedno pending probe or code mismatchThis should give their developers a more specific starting point than ageneral loopback failure.It would also be useful to temporarily test Duplicator with the otherWordPress plugins disabled, preferably on a staging copy or during a safemaintenance period.If Duplicator works with the other plugins disabled, the plugins can thenbe enabled one at a time until the conflict is identified.If the same kickoff error continues when Duplicator is the only activeplugin, this would provide stronger evidence that the behavior isspecific to Duplicator 5.0.2.
       ```
   
 *  Plugin Support [skfaysalalom](https://wordpress.org/support/users/flossyfaysal/)
 * (@flossyfaysal)
 * [5 minutes ago](https://wordpress.org/support/topic/duplicator-version-update-breaks-it/#post-19017505)
 * Hi [@michaelmossey](https://wordpress.org/support/users/michaelmossey/),
 * Thank you so much for this incredibly thorough investigation, and please pass
   along our thanks to your DreamHost team as well. This is some of the most detailed
   diagnostic information we’ve received, and it points us to something very specific.
 * First, some context on what’s new in Duplicator 5.0: we introduced a feature 
   called **Client-Side Kickoff**. Previously, Duplicator relied entirely on the
   server calling itself (a loopback request) to process backup chunks in the background.
   With 5.0, we added a mechanism where the browser can also help trigger these 
   chunks, which is meant to make backups more resilient across different hosting
   environments, including ones where server-to-server loopback requests are restricted
   or unreliable.
 * Now, to the key finding: your DreamHost team’s tests confirm the loopback endpoint
   itself is reachable and returning `HTTP 200` consistently, even under simultaneous
   requests. That’s good, it rules out a firewall or FastCGI exhaustion issue on
   the current tests. However, the important detail is this trace message:
 *     ```wp-block-code
       ClientSideKick.php > confirmLoopbackProbe
       KICKOFF TEST: probe rejected — no pending probe or code mismatch
       ```
   
 * This tells us the request is reaching Duplicator’s code, but Duplicator itself
   is rejecting its own probe due to a mismatch, rather than the request being blocked
   externally. This looks like it could be an issue within the kickoff/probe validation
   logic itself in 5.0.2, possibly related to how the probe token is being stored
   or matched (e.g., caching, object cache, or session handling on your specific
   environment), rather than a generic server block.
 * Given how specific and reproducible this is, we’d like to get our development
   team directly involved. Could you open a ticket with us at [https://duplicator.com/contact](https://duplicator.com/contact)
   and, if you’re comfortable, provide temporary login access (or a staging copy)
   so we can inspect the `confirmLoopbackProbe` behavior directly on your site? 
   This would let us trace exactly why the probe is being rejected despite the loopback
   request succeeding.
 * We know this is affecting your deadlines, and we want to prioritize getting to
   the bottom of it. Thank you again for the exceptional detail, this gives our 
   developers a real starting point instead of a generic “loopback failed” report.
 * Best Regards, 
   Sk Faysal Alom

Viewing 3 replies - 1 through 3 (of 3 total)

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fduplicator-version-update-breaks-it%2F%3Foutput_format%3Dmd&locale=en_US)
to reply to this topic.

 * ![](https://ps.w.org/duplicator/assets/icon-256x256.png?rev=2906985)
 * [Duplicator - Backups & Migration Plugin - Cloud Backups, Scheduled Backups, & More](https://wordpress.org/plugins/duplicator/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/duplicator/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/duplicator/)
 * [Active Topics](https://wordpress.org/support/plugin/duplicator/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/duplicator/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/duplicator/reviews/)

 * 3 replies
 * 2 participants
 * Last reply from: [skfaysalalom](https://wordpress.org/support/users/flossyfaysal/)
 * Last activity: [5 minutes ago](https://wordpress.org/support/topic/duplicator-version-update-breaks-it/#post-19017505)
 * Status: not resolved