Root cause confirmed by direct test:
curl --connect-timeout 5 http://178.104.200.7:5000/Account/Login -> 000
quantengine.service sets ASPNETCORE_URLS=http://127.0.0.1:5000 (loopback
only, by design -- Nginx is the only public entry point, proxying
quant.taxbaik.com to it). The Gitea Actions runner is not the
production host, so its direct curl to $DEPLOY_HOST:5000 was always
going to hit a closed port. Run #2005 is direct proof: "Deploy to
Production" succeeded, the site was reachable over HTTPS the whole
time, and journalctl was clean -- yet "Health Check & Verification"
burned through all 20 retries (60s) because it was polling the wrong
address entirely. This check has likely never once passed on this
service's actual network layout.
Fix: wrap the HTTP-200 / login-content / CSS retry loop in a single
SSH session that runs curl against 127.0.0.1:5000 on the production
server itself -- consistent with how the service-status and DB-error
checks already correctly run remotely. Removed the redundant
per-attempt SSH round trips for service status (now a plain local
command inside the same remote script) and dropped the separate
"Setup SSH (for service check)" step's curl usage entirely.
kjh2064
3c3f2d56c8