[Sites] Public deployment succeeds but production URL resets before headers

What issue are you seeing?

A website created and deployed through ChatGPT Sites reports a successful production deployment and public access, but the production URL does not reach the application.

Production URL:

https://recommendation-fairness-growth.gtlycxl.chatgpt.site/

The user-facing error is:

upstream connect error or disconnect/reset before headers.
reset reason: connection termination

What steps can reproduce the bug?

1. Create a site from Codex Desktop using the bundled Sites workflow.
2. Build and deploy the site.
3. Change sharing to public / anyone with the link.
4. Confirm in Sites that the project is active, not disabled, and the access policy is public.
5. Open the production URL in a browser.
6. Observe that the request is reset before response headers.
7. Save and deploy a completely new version.
8. Add a minimal static health probe at /health.txt.
9. Open both the root URL and /health.txt; the public hosting path still fails.

What is the expected behavior?

A deployment reported as succeeded should serve the generated HTML at the production URL. The minimal static health file should also be reachable.

If the origin or edge route cannot serve traffic, the deployment should be marked failed or provide an actionable hosting error rather than reporting success.

What is the actual behavior?

• Sites reports the project as active and public.
• The latest saved version and a fresh redeployment both report succeeded with no failure message.
• The public URL still fails before the application returns headers.
• A separate access path can also receive a Cloudflare block page, indicating that the request is failing at the edge/dispatch layer before reaching the app.

Diagnostics already completed

• The production build completes successfully.
• The local production server returns HTTP 200 and the correct HTML.
• The generated Worker entry point returns HTTP 200 when invoked locally.
• The packaged deployment artifact matches the validated source state.
• The site has no D1 or R2 bindings and the homepage has no external API dependency.
• Access was changed from owner-only to public and verified after the change.
• A second, newly saved version was deployed after public access was enabled.
• Both the application route and the minimal /health.txt route remain unavailable publicly.
• Reproduced on 2026-07-15 (Asia/Shanghai) in Codex Desktop on macOS.

This looks like a Sites/Cloudflare edge dispatch, origin routing, or deployment propagation issue rather than an application runtime failure.