Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
A 502 Bad Gateway from NGINX means the proxy could not obtain a valid response from its configured upstream application. The fastest fix is not to increase a timeout or replace the error page: reproduce one failing request, read the NGINX error log, identify the upstream address and failure phase, test that backend from the NGINX host or container, and then correct the service endpoint or proxy directive that the log implicates.
This guide covers connection refusals, unreachable hosts, URI mistakes, HTTP-to-HTTPS mismatches, TLS failures, slow responses, malformed or oversized headers, and upstream-group selection failures. It also shows how to validate and safely reload the smallest configuration change.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What a 502 means in an NGINX reverse proxy
NGINX sits between the client and an application server. For each proxied request it sends the request to a configured proxy server, fetches that server’s response, and sends the response back to the client. A 502 means that exchange failed: NGINX did not receive a usable upstream response.
The upstream may be a local process, another machine, a container, or a service selected from an upstream group. NGINX can proxy HTTP and other protocols through directives including proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, and memcached_pass. The exact directive in use determines which endpoint and protocol you must test.
#1 Best Overall
- Powerful Turbo Fan:CAGIWIRU Electric Air Duster have reached speed up to 130000RPM,Can efficient remove dust and debris.With LED light and Three Adjustable Speed to meet with different cleaning tasks.
- With Attached USB C Fasting Charging cable.Charing 3 hours,Enjoy up to 240 minutes of use on the lowest setting, For third speed can use for 25mins.with four charging options to meet with your needs.
- Wide Application: attached 5 different nozzles,making it suitable for a variety of scenes, such as car,pet, pc, keyboards, and other electronic devices. It also serves for office and home clean duster.
- Handy Design & Portable:Cordless air duster electric nozzle is Light weight and small size, design and comfortable to hold and space saving, convenient to carry around. You can put it in your room or inside the car without taking up space.
- Economical &Reusable: Built durable materials with a long-lasting battery,our CAGIWIRU air duster it's a sustainable alternative to disposable air cans.
A 502 is therefore a gateway-to-upstream problem, not proof that the browser, DNS for the public site, or the client request is wrong. The error log normally identifies whether the failure happened while connecting, during a TLS handshake, while waiting for headers, or while parsing the upstream response.
Use this log-first diagnostic sequence
- Find the active error log. Common package installations on RHEL, Debian, and Ubuntu use
/var/log/nginx/error.log. Official container images commonly write the error log to container standard error instead. The absolute path is installation-specific, so check the activeerror_logdirective if the usual file is empty. - Reproduce one failing request. Keep the URL and time noted, then immediately inspect the log. Looking at old entries can lead you to fix a previous incident rather than the current request.
- Classify the message. Search for phrases such as
connect() failed,upstream timed out,invalid header,upstream sent too big header, or a TLS handshake error. Each points to a different remedy. - Write down the upstream shown by NGINX. Record the hostname or IP address, port, scheme, and any upstream-group member. Compare those values with the application’s intended listening endpoint.
- Test from the NGINX runtime. Run a direct request from the NGINX host, or from the NGINX container or pod when NGINX is containerized. A test from your laptop can succeed while the proxy remains unable to reach the service.
- Change only the setting that matches the failure. Fix the listener, route, protocol, certificate, header size, queue, or timeout indicated by the evidence. Then validate the syntax, reload, and repeat the same request.
Make upstream timing visible
When access logs contain only a status code, add upstream timing fields to the relevant log format or inspect an existing format. NGINX defines these variables as follows:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors| Variable | What it tells you | Useful interpretation |
|---|---|---|
$upstream_addr |
The address selected for the upstream request | Confirms which host and port actually received the attempt |
$upstream_connect_time |
Time spent establishing the upstream connection | A long value or a connection error points to routing, firewall, listener, or TLS setup |
$upstream_header_time |
Time until the first response headers arrive | Separates a slow application response from a connection problem |
$upstream_response_time |
Time until the complete upstream response is received | Shows whether the backend remains slow after sending headers |
$request_time |
Total time NGINX spends handling the client request | Provides the client-visible duration for comparison |
These values are diagnostic evidence, not a reason to raise every timeout. A fast connection followed by no headers suggests application work or an upstream dependency; a failure before connection establishment requires a network or endpoint fix.
Test the backend directly from NGINX
Use the exact scheme, host, port, and path configured in the proxy. For a plain HTTP health endpoint, a representative command is:
curl -v http://127.0.0.1:8000/healthReplace the address and path with the real upstream. Run the command in the same network namespace as NGINX. If NGINX is in a container, execute the test inside that container or another container on the same network; 127.0.0.1 there means that container, not the host.
Rank #2
- Screen Cleaner is Your Screen’s New Bestfriend! - EVEO is proud to present a screen cleaner that’s perfectly suited for your TV. Meet your new screen cleaner, computer screen cleaner, laptop cleaner, iPad cleaner, Macbook,tv cleaner or any other electronic device. Our screen cleaner spray and wipe along with the included plush microfiber cloth, easily removes dust, fingerprints & other smudges on the screen’s surface. Clean effectively for a streak-free screen
- Gentle on your Screens - Our screen cleaner spray and wipes is compatible to be used even for the most sensitive LCD, LED, CRT, and OLED screens in proper use. Be at ease knowing that this product is compatible with all the major brands: LG, SONY, Samsung, Sharp, iPad, iPhone, Android screens, Kindle, PC monitors - we’ve got you covered! Can be used as LCD screen cleaner, tv cleaner, smart tv screen cleaner, and more
- Premium Super Soft Plush Microfiber Cloth - Included in this efficient screen cleaning kit. This screen cleaner spray and wipe has our signature plush microfiber cloth specially designed to comply with screens and monitors and leave them streak-free. Has been shown to effectively absorbs stubborn stains, zero streaks, and no fiber shedding. Always use this together with our screen cleaner for the best results
- Easy-to-Use Screen Cleaner Kit + microfiber cleaning cloth - The EVEO Screen Cleaning Kit will easily be your new favorite tool when it comes to taking care of the things you love most, quick and easy solution for a streak-free screen. Simply screw on the sprayer gun on the screen cleaner bottle. Spray the cleaning liquid onto the microfiber cloth, then wipe the screen until desired cleanliness & shine is achieved.
- Quality Screen Care Kit Worth Purchasing - Enjoy a convenient Screen Cleaner anytime, anywhere you need it. Your satisfaction is our top priority. We stand behind the quality of our products and that’s why, you shouldn’t be worrying at all. We manufacture the Best Screen Cleaner. and can be used for laptop cleaning kit, laptop screen cleaner, tv screen cleaner for smart tv. MacBook screen cleaner, monitor cleaner or screen cleaner spray for electronic devices with microfiber cleaning cloth
- Connection refused: no process is listening at that address and port, the port is wrong, or a container or namespace boundary makes the assumed loopback address invalid.
- Connection timeout: the target may be unroutable, blocked by a firewall, bound to a different interface, or otherwise unreachable from the NGINX runtime.
- DNS or name-resolution error: the configured hostname cannot be resolved in the NGINX environment, even if it resolves on another machine.
- A valid application response: basic reachability works; inspect the configured path, protocol, headers, upstream selection, and the difference between the direct request and the proxied request.
Also confirm the process is listening on the intended interface, not only on an address that NGINX cannot reach. Check the application’s own logs at the timestamp of the failed request for crashes, restarts, rejected connections, or malformed output.
Free tools Windows power users keep installed
One-click scans. No signup required.
Correct the common causes
1. The backend is stopped or the port is wrong
A connect() failed message with a refusal usually means NGINX reached the host but found no listener. Check the application service status and its listening address, then compare that value character-for-character with proxy_pass or the relevant upstream directive.
For example, if the application listens on port 8000 but the configuration points to port 8080, change the endpoint or start the service on the intended port. Do not mask a stopped service by increasing proxy_connect_timeout; a timeout cannot create a listener. In a container deployment, verify that the application port is exposed on the container network and that the service name and port refer to the application container rather than the public host port.
2. The host, address, or container name is wrong
proxy_pass can contain a domain name, IP address, and optional port. Resolve and connect to that name from the NGINX runtime, not from an unrelated shell. Verify that NGINX and the backend share the expected container network, that network policies and firewalls permit the connection, and that the address belongs to the intended service.
Multiple interfaces can matter. If the upstream permits only a particular source network, NGINX’s proxy_bind directive can select the source address used for the upstream connection. Use it only when the upstream’s access policy requires a specific local address; it does not fix an incorrect destination or a stopped service.
Rank #3
- 【Large size】：Measuring 800 x 300 mm/ 31. 5×12 inches, which is wider and taller than others. Large mouse pad can perfectly fit your keyboard and mouse of any size, and there is also ample space for peripherals such as phones, tablets, etc.
- 【LED backlight mouse pad】：Blade Hawks RGB mouse pad provides 7 static modes and 7 dynamic modes will give you the options you are looking for. Power-off memory function remembers the last lighting mode you selected. The super glow fiber Chroma will give you a colorful gaming setup that you want.
- 【Anti-slip rubber base】：Made from Natural rubber, this gaming mousepad will firmly grip your desktop, allowing you to enjoy the ultimate precision in the games you are most passionate about. It also comes with a texture that enhances this ability even further.
- 【Smooth and waterproof surface】: Micro-textured cloth surface, for extremely precise mouse control and a smooth movement. When liquid splashes on the gaming mouse pad, it forms water droplets and slides down. Will not delay your work or gameplay.
- 【Plug and play】: This mouse and keyboard pad is powered by USB, plug and play, no driver required. One button control light modes. Press one time to change the lighting mode, press twice to change the brightness, press and hold about 3 seconds turn ON/OFF.
3. The location and trailing slash send the wrong URI
URI handling changes when the proxy_pass value contains a URI. With a URI, NGINX replaces the portion of the request path that matched the location. Without a URI, NGINX passes the full request URI, subject to NGINX’s documented normalization rules.
That distinction can route a request to an endpoint the application does not have. For instance, a location intended to expose the application under /api/ may either preserve that prefix or replace it, depending on whether the proxy target ends with a path. Compare three values before editing: the browser’s requested path, the path produced by the location and proxy_pass combination, and the path the application expects.
After changing a trailing slash or location, test a concrete endpoint rather than only the root page. A route can return an application-level 404 while another path still produces a gateway error, so use the exact URL that originally failed.
4. NGINX and the upstream disagree about HTTP versus HTTPS
Use proxy_pass http://... when the upstream speaks plain HTTP and proxy_pass https://... when it expects TLS. Pointing an HTTP proxy at a TLS port, or sending TLS to a plain HTTP listener, commonly produces a handshake or protocol error in the error log.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →For HTTPS upstreams, check all of the following:
- The certificate name matches the hostname NGINX is using, including any required SNI name.
- The upstream certificate chain is trusted according to the NGINX TLS configuration.
- The upstream actually serves TLS on the selected port.
- The NGINX runtime can resolve and reach the TLS endpoint.
A TLS handshake failure is a protocol or certificate configuration problem. Increasing proxy_read_timeout will not repair it.
Rank #4
- 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
- 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
- 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
- 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
- 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.
5. The connection or response genuinely times out
Use the timing variables and the error message to establish where the delay occurs. A delay during connection establishment implicates routing, firewall rules, listener capacity, or TLS setup. A connection that succeeds but produces no headers points toward slow application work or a blocked upstream dependency.
NGINX provides separate controls: proxy_connect_timeout limits connection establishment, proxy_send_timeout covers sending the request to the upstream, and proxy_read_timeout governs waiting for upstream response data. Review these only after confirming that the backend is healthy and that the observed delay is expected. A larger value can keep clients waiting longer while concealing a dead or overloaded service.
NGINX treats connection errors, timeouts, denied connections, and invalid upstream headers as unsuccessful upstream attempts. If the application is supposed to respond quickly, fix its crash, deadlock, dependency, or capacity issue instead of normalizing an excessive timeout.
6. The upstream closes early or sends invalid or oversized headers
An application that crashes before completing its response, closes the socket early, or emits malformed HTTP headers can cause a 502 even though a listener exists. Inspect application and upstream logs at the matching timestamp and test the same route directly to determine whether the malformed response originates in the application or an intermediate service.
Large response headers can also exceed configured buffering. NGINX Gateway Fabric documents “upstream sent too big header” as a 502 scenario and recommends increasing the response-header buffer size or setting the required buffer at the route level. Apply the smallest buffer change that accommodates the legitimate headers; do not use an unlimited value as a substitute for fixing runaway cookies or headers.
Best Value
- 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
- 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
- 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
- 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
- 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.
7. An upstream group cannot select a server
When a request is sent to an upstream group, NGINX may fail before connecting to an individual application. A full queue or failure to select a server within the configured queue timeout returns 502. Inspect member health, queue limits, and load-balancer selection settings. Correct the unavailable members or queue policy before changing the client-facing error page.
Record which member appears in $upstream_addr and whether failures affect every member or only one. If one member is unhealthy, removing or repairing that member is more effective than raising a global timeout.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallUnderstand the proxy configuration before editing it
Open the active server block and identify the matching location. Then trace the endpoint in this order:
- Determine which public path matched the location.
- Read the complete
proxy_passvalue, including scheme, hostname or IP, port, and any URI. - Check inherited settings that affect TLS, timeouts, buffering, source binding, or upstream selection.
- Compare the resulting upstream request with a direct
curl -vrequest from NGINX’s runtime.
Do not edit an unused configuration file. A syntactically correct change has no effect if the active server block includes a different file, listens on another address, or is superseded by a more specific location. Keep a copy of the original and make one focused change at a time so the next log entry has an unambiguous cause.
Validate and reload safely
- Run
nginx -t. Continue only when NGINX reports that the configuration syntax is valid and the test is successful. - Reload NGINX with the normal service command for the platform. Use the service manager or deployment mechanism that owns the running instance rather than starting a second process manually.
- Repeat one known failing URL and capture its status, response headers, and timestamp.
- Immediately inspect the error log and confirm that the new request no longer produces the original upstream error.
- Check that the response status and body now come from the application, not merely from a custom NGINX error page.
- If the change did not address the logged phase, revert it and return to the direct backend test instead of stacking unrelated edits.
Document the final upstream address, scheme, port, expected path, and the reason for the change. This record makes a later container redeploy, certificate rotation, or port change less likely to recreate the same 502.
Choose the remedy by failure phase
| Observed phase or log pattern | Most likely scope | First corrective action | Do not do first |
|---|---|---|---|
connect() failed or connection refused |
Backend process, listener, port, or namespace | Verify the service is listening and direct-connect from NGINX | Raise a read timeout |
| Connection timeout | Routing, firewall, source address, or unreachable host | Test reachability from the NGINX runtime and inspect network policy | Change URI rewriting |
| TLS handshake error | Scheme, TLS port, certificate name, SNI, or trust | Match http/https and verify certificate and SNI requirements |
Increase proxy_read_timeout |
| Headers never arrive | Slow, blocked, or unhealthy application | Compare connect and header timings with application logs | Assume the browser is at fault |
| Invalid header or upstream closes early | Application output or an intermediate gateway | Inspect direct response and upstream crash logs | Hide the 502 with a custom page |
| Upstream sent too big header | Response-header buffering or oversized application headers | Reduce unnecessary headers or increase the relevant buffer deliberately | Apply an unbounded buffer |
| Queue or server-selection failure | Upstream-group health, queue limits, or selection policy | Check member health and queue configuration | Change all client timeouts indiscriminately |
Prevent repeat 502 incidents
- Keep a health endpoint that can be requested from the NGINX network and use the same scheme and port as production traffic.
- Log
$upstream_addrand the four timing variables so connection, header, body, and total request delays can be distinguished after an incident. - Keep service discovery names, container-network membership, and exposed ports documented alongside the NGINX configuration.
- Test certificate names, SNI behavior, and trust settings whenever an HTTPS upstream is introduced or rotated.
- Monitor application restarts, listener availability, queue saturation, and malformed-response errors rather than treating every 502 as a frontend event.
- Use configuration review to catch URI and trailing-slash changes before deployment, and run
nginx -tin the release process.
When a 502 is not the right diagnosis
If a direct request from the NGINX runtime succeeds but the public request fails, compare the selected location, rewritten URI, headers, and upstream protocol. If the log shows a long wait for a response rather than a connection failure, the underlying issue may be application latency even though NGINX ultimately reports a gateway error. If the log identifies a TLS handshake or oversized header, treat that specific phase as the problem instead of labeling the incident generically as “the proxy is down.”
The reliable workflow remains the same: identify the active log, reproduce once, test the exact upstream from the NGINX runtime, fix the phase-specific cause, validate with nginx -t, reload normally, and verify the same URL.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
