ERR_CONNECTION_RESET issues during Shopify app review

Shopify App Store
1

Has anyone experienced random ERR_CONNECTION_RESET issues during Shopify app review?

My app review was paused because the reviewer could not access the app domain. However:

  • The embedded app initially loaded correctly inside Shopify Admin

  • In the database I saw the record that application installed (it is mean that endpoint/domain worked)

  • Reviewer reached the login screen for entered credentials

  • Later navigation to application domain and it returned ERR_CONNECTION_RESET

  • Nginx/Laravel logs show no application errors

  • Docker containers were healthy

  • Shopify uninstall webhook was successfully delivered afterwards (HTTP 200)

Infrastructure:

  • Laravel + Docker + Nginx

  • Cloudflare proxy enabled

  • Browser Integrity Check was enabled at the time (now disabled)

I’m trying to understand whether this is likely:

  • Cloudflare/Bot protection related

  • IPv6/network routing issue

  • embedded iframe/session issue

  • or something Shopify reviewer environment commonly triggers.

Would appreciate any insights from people who went through Shopify app review.

2

Hi, we’re also facing the same issue. Hope the problem gets resolved quickly.

3

Hey @Alexander_T and @controleng - thanks for flagging this and sharing the details here.

I’m seeing a couple similar reports around app review loads failing with ERR_CONNECTION_RESET while the app is reachable elsewhere and, in some cases, no browser-initiated requests appear to reach the app server. I can’t confirm from the forum alone whether these all have the same cause, but it’s enough of a pattern that I’m going to look into it further on our end.

To help route this with the right context, could each of you share:

  • app ID or Partner org
  • the most recent rejection timestamp and timezone
  • app URL and any review-facing redirect domains
  • whether you already have a Partner Support ticket open

Happy to set up a DM if you’d rather keep those details private.

One thing worth double-checking in the meantime is that the app URL, auth callback, and any external redirect domains are reachable without geo/IP/VPN restrictions, bot challenges, browser integrity checks, or similar protections that could block the reviewer before the request reaches your app server.

Let me know and I can dig further on our end here.

4

Hi,

Our embedded app was rejected during manual review because the reviewer encountered an ERR_CONNECTION_RESET when loading the app. We are looking for guidance, as this issue seems isolated.

Setup: Railway (Hosting), Squarespace (DNS).
App URL: https://chronos.cymage-labs.com
Callback: Price History & Schedules | Shopify App

Organization: Cymage Labs
Organization ID: 4644230

App ID: 302026194945

What we verified:

Shopify Partner configs and Railway env variables match perfectly.

Global DNS resolves correctly to the Railway custom domain (no unexpected IPv6/AAAA records).

Global HTTP, ping, and health checks consistently succeed from multiple regions.

The Core Issue:Shopify automated test installations successfully reached our app and generated production logs. However, the manual reviewer’s traffic never reached our Railway logs at all, failing with ERR_CONNECTION_RESET.

Has anyone experienced this exact scenario where automated tests pass, but the manual reviewer gets blocked before hitting the server?

We are trying to determine if this is typically caused by:

The reviewer’s local network, VPN, or proxy dropping the connection.

Transient Railway edge routing or TLS handshake issues.

Specific Shopify embedded app loading behavior during manual review.

Any insights or debugging strategies would be greatly appreciated.

5

Hi, thank you for your replay.

Now it re-reviwed and everyhing is ok. Problem was
App id is 353198407681
reproduced: May 12, ~16-16:30 Warsaw TZ

6

Hey @Alexander_T and @controleng -

@Alexander_T, thanks for the update. Glad to hear the re-review went through! Let me know if we can help out further though :slight_smile:

@controleng, thanks for sending all that info, really appreciated. I checked the public app URL and I’m not seeing an obvious DNS/TLS reachability issue from my end. Given that automated install traffic reached your app but the manual reviewer’s traffic never appeared in your Railway logs, this lines up more with a reviewer-network or URL filtering issue than an embedded app/session issue from what I can tell.

Could you share the most recent rejection timestamp and timezone, plus whether you already have a Partner Support ticket open? With that, I can route the app ID/org/app URL with the right context on our end.

In the meantime, I would say to keep any bot challenges, geo/IP/VPN restrictions, browser integrity checks, or similar protections disabled for the app URL, auth callback, and any review-facing redirect domains. Hope to hear from you soon

7

Thanks for checking and for the guidance.

The most recent rejection timestamp was May 12, 2026 at 01:48 Turkey time (TRT / UTC+3).

We do not currently have a Partner Support ticket open for this issue.

We also confirm that we do not have any bot challenges, geo/IP/VPN restrictions, browser integrity checks, WAF rules, or similar protections enabled for the app URL, auth callback, or review-facing redirect domains. The app URL is hosted directly through Railway with the custom domain “https://chronos.cymage-labs.com”.

Please let us know if you need any additional details from our side.

8

Hi, just following up — is there any update from the Shopify review team on this issue?

9

Hey @controleng - thanks for the follow-up and for confirming those details.

I don’t have a confirmed review-team update to share yet, but based on the pattern here, the best next step is to resubmit the app through the Partner Dashboard and include the relevant context directly in the App review instructions: the previous rejection timestamp, confirmation that the app URL is reachable, and the server log detail showing that the manual reviewer’s request did not reach Railway while Shopify automated/install-related traffic did.

I’d also include that you’ve confirmed there are no bot challenges, WAF rules, geo/IP/VPN restrictions, or browser integrity checks on the app URL, callback, or review-facing redirect domains.

If the same connection reset happens again after resubmission, please feel free to ping me here with any fresh log details here, and I can help route that with more current context on our end.

10

Thanks for the update, Alan.

One important clarification: this same connection reset issue has happened in two separate review attempts, not only once.

The relevant rejection timestamps are:

  • First rejection: May 4, 2026 at 20:50 Turkey time (TRT / UTC+3)
  • Most recent rejection: May 12, 2026 at 01:48 Turkey time (TRT / UTC+3)

In both cases, the reviewer saw the app fail to load with a connection reset, while our Railway logs did not show the manual reviewer’s request reaching our application service. At the same time, Shopify automated/install-related traffic did reach the app and generated logs.

Because this has happened twice, we are a bit concerned that simply resubmitting without any confirmation from the review side could lead to the same rejection again. If you are able to get any confirmation or route this context to the review team before we resubmit, we would really appreciate it.

If that is not possible, please let us know as well, and we can proceed with resubmission while including all of this context directly in the App review instructions.

Thanks again for your help.

11

hey @Alan_G

APP ID : 342474096641

Our app Tuck — Realistic Virtual Try On was rejected during review because the reviewer encountered a “The connection was reset” error immediately upon attempting to open the app after installation.

The reviewer installed our app at approximately 8:04 PM IST (14:34 UTC) on May 14, 2026, and uninstalled at 8:16 PM IST (14:46 UTC). During that 12-minute window, the reviewer saw “The connection was reset” inside the Shopify Admin embedded app iframe.

What my server logs show

I analyzed the complete server logs covering 2.5 days (May 12, 07:18 UTC → May 14, 19:54 UTC — over 386,000 lines). The reviewer’s shop (xqiz3u-i1.myshopify.com) appears in exactly 3 log entries, all at the same timestamp, all from the uninstall webhook:

2026-05-14T14:46:16.284Z [shopify-app/DEBUG] Loading offline session | {shop: xqiz3u-i1.myshopify.com}
2026-05-14T14:46:16.286Z Received APP_UNINSTALLED webhook for xqiz3u-i1.myshopify.com
2026-05-14T14:46:16.402Z Cleaned up local DB data for uninstalled shop: xqiz3u-i1.myshopify.com

What is completely missing from the logs:

  • No GET /?shop=xqiz3u-i1.myshopify.com&embedded=1 (initial app load)

  • No GET /auth/callback (OAuth flow)

  • No Creating new session for this shop

  • No Running afterAuth hook

  • No request of any kind from this shop’s browser — ever

The APP_UNINSTALLED webhook (server-to-server from Shopify’s backend) worked perfectly. The browser-initiated install/load request never reached my server.

What I verified

1. Other installs work fine in the same logs: Two other shops (tuckdemo.myshopify.com and connect-yysnf9gr.myshopify.com) completed full install flows during the same log window — session creation, OAuth, afterAuth, VTO registration, webhook setup, metafields — everything worked.

2. Server was healthy at the time of review: ELB health checks were passing continuously with 4–6ms response times throughout the reviewer’s install window. No errors, no restarts, no resource issues.

3. Tested from Finland via VPN: The reviewer appears to be based in Finland. I connected to a Finland VPN (Windscribe, Helsinki server) and tested:

Result: HTTP 200, TLS 1.3, full HTML response, no issues. The server is fully reachable from Finland. The connection is not being blocked by my infrastructure.

4. SSL is valid: Certificate issued by Amazon RSA 2048 M01, valid Apr 16 – Oct 30, 2026. TLS 1.3 with TLS_AES_128_GCM_SHA256. No certificate chain issues.

5. No geo-blocking or IP restrictions: My ALB security group allows inbound 443 from 0.0.0.0/0. No WAF rules, no geo-restrictions.

Thank you for your time. Happy to provide full server logs or any other evidence if neede

12

Hi @Alan_G
Can a reviewer change the app’s credentials?

The situation is that, following the second review, I had only one comment, and it concerned the Billing API. I fixed that – it just required a code change, which I made and submitted for review. When I logged in just now, I saw a message about a problem with the test credentials. I checked, and indeed the password for the account used for testing did not match the required one (there was a 1 before the password). But there are two oddities here: 1) the password was valid in the previous review and had not been changed in the givi****.com system; 2) I did not change the description in the Listing

It seems that the issue with ERR_CONNECTION_RESET and the account password is man-made.

However, I won’t be able to send the next review until 4 June.

13

Hey @controleng - thanks for clarifying that this happened across two separate review attempts. That changes the shape of this a bit, so I’m going to dig into this further on my side.

I also checked the app URL from my end and it’s reachable, so with your logs showing no manual reviewer browser request reaching Railway while Shopify server-side traffic did reach the app, this does seem odd. I’ll reach out to some folks internally on this for you.

If you’re able to open a Partner Support ticket as well, that would help keep the review context attached in the right place. In the meantime, if you do resubmit, include those two timestamps, the “no browser request reached Railway” detail, and confirmation that there are no bot challenges, WAF rules, geo/IP/VPN restrictions, or browser integrity checks enabled.

@Richu_Jose - thanks for the detailed logs here too. I took a look here, and it seems like your case has already been handled on the review side, but let me know if you’re still seeing anything blocked in Partner Dashboard.

15

Hey @controleng - I’ve been working with some folks on this just now - can you try resubmitting and let me know when you do? We’re just working through things on our end now.

@Alexander_T - thanks for flagging. I can definitely look into this for you - I’ll DM you on my end :slight_smile:

16

Hi Alan,

Thanks for the update and for looking into this with the relevant teams.

As requested, we have resubmitted the app through the Partner Dashboard.

Resubmission timestamp:
May 22, 2026 at 10:19 Turkey time (TRT / UTC+3)

17

Thanks @controleng - I’ve let the team know you’ve resubmitted. Feel free to ping me here if I can help out further!