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
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Nginx upstream timed out (110) means Nginx, acting as a reverse proxy, could not complete one stage of its conversation with the backend before that stage’s timeout expired. The text after while identifies the stage: connecting, sending the request, waiting for response headers, or reading the response body. A browser or API client commonly receives HTTP 504 Gateway Timeout when Nginx gives up.
The right fix is not automatically “increase proxy_read_timeout.” First identify the failed phase, measure where the time is being spent, and then correct the backend, network, retry, or timeout setting that actually limits the request.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11What “upstream timed out (110)” means
Nginx uses an upstream definition such as proxy_pass http://app_backend; to forward a client request to an application server. Each forwarded request has several phases:
- Establish a connection to an upstream address and port.
- Transmit the request to that upstream.
- Wait for the upstream to send response headers.
- Continue receiving the response body.
The Linux error number 110 is the operating-system “connection timed out” condition. Nginx adds a phrase describing the phase in which no progress occurred. A timeout is an observation about progress, not proof that the application is permanently down: the backend may be overloaded, blocked on a database, waiting on a client, or simply taking longer than the configured idle interval.
#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.
When Nginx abandons the attempt before sending a response to the client, it generally returns 504 Gateway Timeout. The error log is more useful than the status code because the suffix tells you where to investigate.
Use the error-log suffix to find the failing phase
| Error-log text | What Nginx was waiting for | First places to investigate |
|---|---|---|
while connecting to upstream |
A TCP connection (and, where applicable, a TLS handshake) to the backend. | Address and port, DNS results, IPv4/IPv6 routing, firewall rules, listener state, accept queue, and whether the service is running. |
while sending request to upstream |
Progress writing the request bytes to a backend that is not reading quickly enough. | Request size, upload buffering, congested links, upstream receive behavior, and backend saturation. |
while reading response header from upstream |
HTTP response headers from a backend that accepted the request but has not begun responding. | Application traces, database calls, worker pools, queue depth, CPU, memory, and slow or blocked dependencies. |
while reading upstream |
More response-body bytes after the backend started responding. | Slow queries, file or object-storage reads, response generation, compression, client backpressure, and streaming heartbeats. |
The phase matters because changing a read timeout cannot repair a failed TCP connection, and changing a connect timeout cannot make a slow database query finish sooner.
Nginx proxy timeout directives and their behavior
| Directive | Documented default | Timer measures | Important qualification |
|---|---|---|---|
proxy_connect_timeout |
60 seconds | Time to establish the upstream connection. | Nginx documents that this value usually cannot exceed approximately 75 seconds because of the network stack. |
proxy_send_timeout |
60 seconds | Idle time between two successive writes while sending a request. | It is not a fixed total upload-duration allowance. A connection can send for longer than 60 seconds if each write makes progress within the interval. |
proxy_read_timeout |
60 seconds | Idle time between two successive reads from the upstream. | It is not the maximum lifetime of the response. A backend that periodically sends bytes can remain connected for much longer. |
These directives can be set in the http, server, or location context. A more specific context overrides a broader one, so always inspect the effective configuration rather than assuming a value from a file you edited.
Idle timeout versus total request time
Nginx’s read and send timers are progress timers. For example, with proxy_read_timeout 60s, a response may last ten minutes if the upstream sends at least one chunk within every 60-second interval. Conversely, a response that is expected to take 90 seconds but sends no headers for the first 61 seconds will time out. A slow operation may therefore require application optimization, a queue, or an intentionally larger idle budget rather than an arbitrary “request timeout” increase.
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
Safe diagnostic workflow
Follow these steps in order. Record the timestamp and request identifier if your logs include one, so every observation can be correlated across Nginx and the application.
- Capture the complete error line. Preserve the upstream address, port, phase suffix, request path, and timestamp. The exact phrase distinguishes connection, upload, header, and body failures.
- Confirm the client-facing result. Check whether the request returned 504 and whether the response was generated by Nginx or by the application. A 504 means Nginx stopped waiting; it does not identify the underlying bottleneck by itself.
- Inspect the active configuration. Run
nginx -Twith the privileges used by your installation and find the matchinglocation,proxy_pass, and all applicableproxy_*_timeoutdirectives. Look for an included file or nested location that changes the value. - Correlate access and application logs. Match the request time and path with backend logs, traces, database timings, worker utilization, and queue depth. If configured, examine
$upstream_connect_time,$upstream_header_time, and$upstream_response_time. These values help separate connection delay from time spent before headers and while transferring the body. - Test the exact network path from the Nginx host. Resolve the upstream name and test TCP connectivity to every returned address and port. Test both address families when DNS returns IPv4 and IPv6. A test from your laptop is not equivalent to a test from the proxy host.
- Check the backend listener and host health. Verify that the process is listening on the expected address, that local firewall rules allow the connection, and that service logs show no crash, restart, TLS, or accept-queue problem. Inspect CPU, memory, file descriptors, kernel listen/backlog pressure, and connection counts.
- Look for retries. Comma-separated upstream timing or address values can indicate that Nginx tried multiple servers. A client-visible delay may include several failed attempts, not one slow backend.
- Change the smallest relevant setting. Apply a measured timeout or retry adjustment only after identifying the phase. Then validate and reload the configuration, and confirm the reload in the error log.
nginx -t
nginx -s reloadIf the timeout appears unchanged after editing, do not assume Nginx ignored the directive. A failed reload leaves the old workers serving traffic. Maxim Dounin, an Nginx maintainer, described this situation as: “This suggests that reload wasn’t successful for some reason.” Check the output of nginx -t, the service manager’s logs, permissions, syntax, and the Nginx error log before testing again.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsFixing “while connecting to upstream”
This message means Nginx could not complete connection establishment before proxy_connect_timeout expired. Typical causes are a wrong hostname or port, a stopped process, a firewall or route that drops packets, an unsuitable IPv6 address, a delayed TLS handshake, an overloaded accept queue, or a backend that has run out of connection capacity.
Checks from the Nginx host
- Resolve the configured upstream name and compare the result with the address in the error log.
- Attempt a TCP connection to the exact address and port using an approved diagnostic tool.
- Confirm the backend is listening on an address reachable from the proxy, not only on loopback.
- Review host and network firewall rules, security groups, routes, and recent DNS changes.
- Inspect the backend’s accept queue, process limits, and service logs for saturation or restarts.
Increase proxy_connect_timeout only when measured network or handshake latency is legitimate and intermittent. The documented default is 60 seconds and the usual practical ceiling is about 75 seconds; a larger value is not a substitute for repairing a dropped route, dead listener, or overloaded host.
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.
Fixing “while sending request to upstream”
Here Nginx connected, but the upstream stopped accepting request bytes quickly enough. Large uploads, request buffering choices, a congested path, or an application that has stopped reading its socket can all produce this phase.
What to inspect
- Request body size and whether uploads are buffered before proxying.
- Whether the backend reads the request incrementally or waits for another resource first.
- Network retransmissions, bandwidth limits, and packet loss between proxy and backend.
- Backend worker and connection saturation, including limits on concurrent uploads.
- Any location-specific buffering or request-size directives that differ from the intended policy.
proxy_send_timeout is an idle interval between writes. Raising it does not create a fixed total upload budget and will not cure a backend that is no longer reading. Correct the receive path or capacity problem first, then set a value that accommodates the largest expected idle gap.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Fixing “while reading response header from upstream”
This is the classic application-latency failure. The backend accepted the request but did not produce HTTP headers before the read idle timer expired. The delay may be in application code, a database, an external API, a lock, a worker queue, or garbage collection rather than in Nginx.
Measure before changing the timeout
- Trace the request from Nginx through the application and database.
- Compare the slowest legitimate execution time with the current
proxy_read_timeout. - Check worker availability and queue depth; a full pool can delay even cheap requests.
- Inspect CPU, memory pressure, database locks, connection pools, and downstream service latency.
- Separate rare outliers from a workload whose normal latency has outgrown its original budget.
If the operation is expected, capacity is sufficient, and users can tolerate the wait, increase the read timeout in the narrowest location that needs it. If the operation is unbounded or ties up scarce workers, optimize it, move it to a background job, or return a job identifier instead of holding a proxy connection open.
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.
Fixing “while reading upstream”
The backend sent headers or some body data, then stopped sending bytes for longer than the read idle interval. Investigate slow result generation, large disk or object-store reads, compression, a blocked stream, and client backpressure.
Streaming and WebSocket connections
For a streaming response, send data or an application-level heartbeat often enough to stay below the idle threshold. Nginx’s WebSocket documentation states that a proxied connection closes by default when the server sends no data for 60 seconds. WebSocket locations generally need HTTP/1.1 and the Upgrade and Connection headers:
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 →map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
location /chat/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 10m;
}The ten-minute value is an example, not a universal recommendation. Choose an idle timeout that exceeds the documented heartbeat interval and verify that long-lived connections fit the backend’s worker, memory, and file-descriptor limits.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Retries, failover, and why a timeout may be hidden
proxy_next_upstream has the documented default error timeout. When eligible, Nginx can try another server after a connection error, request-transmission error, response-header error, or timeout, as long as it has not already sent a response to the client. The first backend failure may therefore be invisible while the retry consumes additional time and capacity.
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.
Bound retry behavior with proxy_next_upstream_timeout and proxy_next_upstream_tries when a failing pool could create a retry storm. Consider idempotency carefully: Nginx does not normally retry methods such as POST after the request has been sent unless the non_idempotent option is enabled. Retrying a payment, order, or other side-effecting request can duplicate work unless the application provides idempotency protection.
Passive failure marking
In an upstream group, the documented defaults are max_fails=1 and fail_timeout=10s. Repeated unsuccessful attempts can temporarily mark a server unavailable for that interval. A single-server upstream group ignores these passive marking parameters, so one backend still needs direct availability and capacity monitoring; there is no second server to receive traffic.
Active health checks
NGINX Plus active HTTP checks use a documented default interval of 5 seconds and accept response codes from 200 through 399 by default. These checks test an endpoint independently of live user requests, whereas passive marking reacts to proxy traffic. Select an endpoint that verifies meaningful application readiness without triggering expensive work.
Example: a bounded slow-report location
The following configuration deliberately allows a report endpoint more time for response headers while limiting retries. Replace the values with budgets measured for your own application:
location /reports/ {
proxy_pass http://reports_backend;
proxy_connect_timeout 10s;
proxy_send_timeout 30s;
proxy_read_timeout 180s;
proxy_next_upstream error timeout;
proxy_next_upstream_timeout 20s;
proxy_next_upstream_tries 2;
}After editing, run nginx -t and reload only if the test succeeds. Verify the new worker processes and watch both access and error logs while exercising a known report request. A larger read timeout should be paired with backend limits so a surge of slow reports cannot exhaust all workers.
Choosing a fix by symptom
| Observed evidence | Most defensible next action | Change to avoid |
|---|---|---|
| TCP tests fail or the listener is absent. | Repair DNS, routing, firewall, service state, or listener capacity. | Raising a proxy timeout to mask an unreachable server. |
| Connection succeeds but request writes stall. | Fix upload buffering, receive behavior, congestion, or backend saturation. | Treating proxy_send_timeout as a total upload allowance. |
| Backend traces show predictable work just beyond the header timeout. | Optimize the work or set a narrowly scoped read budget that matches capacity. | Increasing every location’s timeout globally. |
| Headers arrive, then body gaps exceed the idle interval. | Fix generation or storage delays, add stream heartbeats, or adjust the idle value. | Assuming a long-lived stream is safe without connection-capacity planning. |
| Several upstream addresses appear in logs. | Review retry limits, server health, and request idempotency. | Adding unlimited retries to compensate for unhealthy nodes. |
Common mistakes
- Changing the wrong directive: a connect failure is not a response-read failure.
- Confusing idle and total time: send and read timers reset when progress occurs.
- Editing an inactive file: included files, containers, alternate prefixes, and nested locations can make the edited value irrelevant.
- Reloading without validation: a syntax or permission error leaves old workers running.
- Ignoring retries: failover can multiply backend work and make a single failure look like a long request.
- Raising limits without capacity planning: more waiting connections consume workers, memory, sockets, and database connections.
- Retrying side effects: non-idempotent requests need application-level protection before failover is enabled.
When a timeout increase is appropriate
Increase a timeout only when all of the following are true: the failing phase is known; the delay is expected and measured; the backend has enough worker, memory, database, and connection capacity; the client can tolerate the wait; and retry behavior will not multiply the load. Otherwise, the durable fix is to remove the bottleneck, queue the work, add capacity, repair connectivity, or redesign the response as a stream or asynchronous job.
Free tools Windows power users keep installed
One-click scans. No signup required.
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.
