Paul

Hi @smashballoonlouis

Thanks for the feedback, question is the link is it just a rollback to 2.6.2 from 2.6.2

Thanks
Paul

Hi @wfpeter

Thanks for your reply. Here is a clearer summary of the issue on our multi-instance WordPress setup (Azure App Service, 2+ backend instances).Issue Description

After entering a valid 2FA code, the login page reloads and eventually displays:

“CODE INVALID: The 2FA code provided is either expired or invalid. Please try again.”

This only occurs when the 2FA validation request is handled by a different instance than the one that generated the MFA challenge.
With 1 instance, Wordfence MFA works perfectly.

Note: The user can eventually log in, but only when the request happens to land back on the same instance where the MFA challenge was originally created.Cause Identified

The issue occurs when the following W3 Total Cache setting is enabled: ❌ Enable caching for wp-admin requests

When enabled, wp-admin and MFA-related pages are cached, causing:

• MFA token generated on Instance A
• Validation request processed on Instance B
• Instance B lacks the required MFA transient/nonce
• Wordfence returns the “invalid code” error
• Login loops

Disabling wp-admin caching resolves the issue immediately. ✔️ The following setting is safe to keep enabled:

Store transients in database
This ensures MFA-related transient data is shared across all instances.Request for Guidance

Could you please confirm Wordfence’s recommended configuration for:

• Multi-instance / load-balanced WordPress environments
• Using Wordfence MFA with caching plugins
• Any wp-admin caching settings that should remain disabled for compatibility

Thanks again

Hi Marko,

Yes, I did also send a support email…

So based on my testing the key finding was that W3 Total cache applies different configurations for Apex/Root domain vs. Subdomains.

Since the duplicate query string issue (?x71967&x71967) appears in the HTML source code, this confirms that W3 Total Cache (W3T) is generating the duplicate versioning before the request even reaches Azure Front Door.

Additionally, the fact that subdomains (cdn.saaslabs.com.au) do not have the issue, while root domains [ redundant links deleted ] do, means W3T is applying different caching logic depending on the domain type. Is there any thing that I can review further on my end? Or a workaround?