Jetpack showing invalid URL, live site linked to staging URLs

  • Resolved Manoj Jamble

    (@manoj239)


    5 months, 1 week ago

    Hi Team,

    When trying to connect our multisite setup, the main site (cosmos.coop) is connected properly. However, the other two sites (metascycosis.com and untimelybooks.com) are not connecting correctly. In the Jetpack dashboard, they show as “connected,” but still display the option to “Connect your site.” Clicking this option results in an error message:
    Error: Invalid request, please go back and try again.
    Error Code: invalid_request
    Error Message: The URL stored by the Jetpack servers does not match your site. Please try disabling the Jetpack plugin, re-enable it, then connect again.

    On WordPress.com, these sites appear, but their URLs are set to the staging URLs. I have verified in the WordPress admin dashboard that the URLs are correctly set to the live sites. It seems that Jetpack has already synced the staging URLs, and the incorrect mapping is not being removed.

    Attempts to remove the sites from WordPress.com fail. When I click “Leave Site,” it asks for transfer of ownership, but nothing happens when I proceed.

    Could you please guide me on how to resolve this and establish a proper connection for the live sites?

    Thank you!

Viewing 7 replies - 16 through 22 (of 22 total)
1 2
  • Thread Starter Manoj Jamble

    (@manoj239)

    3 months, 1 week ago

    Hi Sebastian,

    Thank you for the update and for rechecking on your end.

    I have coordinated with the hosting provider, and XML-RPC was previously restricted by a security rule. We have now allowlisted all Jetpack IP addresses as documented here:
    https://jetpack.com/support/how-to-add-jetpack-ips-allowlist/

    When accessing xmlrpc.php directly via a browser, the request is evaluated using our local IP addresses, which are not included in the allowlist. Jetpack’s servers however are now properly allowlisted, so the browser check does not reflect the actual Jetpack connection status.

    Could you please run the connection test again from your side using the Jetpack service IPs? If any additional IP ranges need to be included, we can add those promptly.

    Appreciate your continued assistance.

    Plugin Contributor Stef (a11n)

    (@erania-pinnera)

    3 months, 1 week ago

    Hi there, @manoj239,

    Thanks for your continuos patience and cooperation whilst we work on having all your sites well connected to Jetpack 🙂

    I checked the two sites that still are having troubles connecting, and sadly I can see that the xmlrpc.php files are still showing up online with the Forbidden error:

    The error message persists also when removing the ?for=jetpack bit, and switching the endpoint to an alternate channel didn’t help too: the connections still result being blocked.

    At this point, we still recommend checking if Cloudflare is still conflicting: try temporarily disabling it and seeing if the connection works this way. If it does, we know at least where we need to focus our efforts.

    Let us know what you find out, thanks!

    Thread Starter Manoj Jamble

    (@manoj239)

    3 months ago

    Hi Team,

    Thank you for your assistance so far.

    I wanted to clarify two points:

    1. XML-RPC access
      We have disabled XML-RPC on the site due to brute-force security concerns. However, Jetpack IP ranges are whitelisted. In this configuration, should Jetpack continue working normally? Or does XML-RPC need to be fully enabled for stable connectivity? This is handled via cloudways.
    2. Connection issues after cloning to staging
      As mentioned earlier, when we clone the live site to staging, the staging environment overrides the wp-config.php file. This removes the WP_ENVIRONMENT_TYPE setting, and Jetpack then reconnects to the staging site instead of the live site. When WordPress.com disconnects due to this, WooPayments also breaks on the live site, which is a critical issue.

    Could you please advise on best practices to prevent the Jetpack and WooPayments connection from switching to staging during future cloning operations? Any configuration recommendations or deployment workflow guidance would be greatly appreciated.

    Plugin Support fujifika (a11n)

    (@fujifika)

    3 months ago

    Hi there,

    1. Yes, you do need to have XML-RPC available for Jetpack to fully function, we have a great page explaining more about Jetpack and XML-RPC here. Having Jetpack’s IP ranges whitelisted is definitely good, this helps ensure the connection traffic isn’t blocked and if brute-force is a concern, you can ask your host for help to lock down xmlrpc.php so it only accepts requests from Jetpack’s IP ranges rather than disabling it entirely.

    2. Have you had a chance to follow the exact steps outlined here?

    That guide explains how to define WP_ENVIRONMENT_TYPE before cloning and use Jetpack’s Safe Mode to prevent this from happening again. Following that process ensures your staging copy won’t override the live Jetpack or WooPayments connection in future deployments.

    Let us know if you have any further questions!

    Plugin Contributor Stef (a11n)

    (@erania-pinnera)

    2 months, 3 weeks ago

    Hey @manoj239,

    Usual check after one week of thread inactivity to hear if you need more assistant or help; otherwise, we’ll mark the thread as solved. Look forward to your reply, thanks!

    Thread Starter Manoj Jamble

    (@manoj239)

    2 months, 2 weeks ago

    Hi team,
    I tried cloning the site again using the recommended steps, including cloning the files first, removing Jetpack, adding wp_environment_type as staging in wp-config.php, and then cloning the database. The site still connected to the staging URLs.

    I also tested multiple cloning approaches and found that if I remove the jetpack_options and jetpack_private_options entries from the database for each site in the multisite, before the first login, the sites do not connect to staging.
    Additionally, the safe mode or fresh connection prompt is not appearing for this site.

    One more request, I attempted to connect both live and staging so that the connections would not override each other, but after cloning, WordPress.com displayed two connections with staging URLs. This was confusing, and currently, WordPress.com still shows those staging URLs as connected, even though they are not connected from the WordPress dashboard.
    Could you please remove the following staging URLs from WordPress.com/sites?

    Plugin Support Tamirat B. (a11n)

    (@tamirat22)

    2 months, 2 weeks ago

    Hi @manoj239 ,

    Thanks for the reply.

    To remove the staging sites currently showing on your WordPress.com account, you can disconnect them manually by following these steps:

    If you’re unable to disconnect them this way, we’ll need to verify ownership to proceed from our side. In that case, please reach out directly via our contact form here using the email address for your WordPress.com / Cloud.Jetpack.com account: https://jetpack.com/contact-support/.

    Look forward to your follow-up.

    Best,

Viewing 7 replies - 16 through 22 (of 22 total)
1 2

You must be logged in to reply to this topic.