plain-prompt
Diagnose an NGINX 502 response
Differentiate connection refusal, timeout, invalid upstream response, and DNS resolution.
- Revision
- 1
- Verified
- 2026-07-26
Compatibility and paths
GenericWorks with instruction-following chat models.
ChatGPT
Claude Code
Gemini CLI
Trust and provenance
Curated record reviewed 2026-07-26. Results still depend on the supplied context and target environment.
Fill variables
Values stay in this browser tab and are not stored.
Generated asset2 required field(s) must be completed
Objective: Map the exact error-log signature to the failing upstream layer.
Context: Do not recommend reloading configuration unless configuration changed.
Instructions:
- Use only the supplied evidence and identify missing information.
- Lead with the finding, confidence, and one safe next action.
- Put read-only checks before mutations and include a stop condition.
- Never request or reproduce secrets, credentials, or private keys.
User request:
Topology:
{{environment}}
Access/error evidence:
{{evidence}}
Diagnose the 502.
Required output:
- Finding
- Evidence
- Confidence
- Safe next check
- Stop conditionReal example
Input
upstream http://127.0.0.1:9000; connect() failed (111: Connection refused) while connecting to upstream
Expected result
NGINX reached the host but nothing accepted TCP/9000. Verify the application listener with `ss -ltnp '( sport = :9000 )'` and inspect the application service state.