Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →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.
NGINX error 111 means the proxy reached the configured upstream address, but the connection was actively refused. Usually, nothing is accepting connections on the selected port, the application is listening on a different interface, or NGINX is using the wrong address. The browser or API client commonly receives HTTP 502 Bad Gateway.
Start with the upstream: value in the matching error-log entry. Test that exact host and port from the NGINX host or container, then correct the process, listener, network policy, address family, or loaded configuration that does not match reality.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What “connect() failed (111: Connection refused) while connecting to upstream” means
A reverse proxy has to establish a TCP connection before it can forward an HTTP, FastCGI, uWSGI, SCGI, memcached, or stream request. In the error case, an NGINX worker attempted the configured upstream socket and received operating-system error number 111, Connection refused. The destination address was reached, but no accepting socket completed the connection.
An official NGINX log example contains fields similar to:
#1 Best Overall
- Read Before You Buy — No Video Output: These adapters support charging and USB 2.0 data transfer, but cannot transmit video signals. Except for standard USB webcams (which use USB data only), they are not compatible with HDMI/DisplayPort cables, video-capable USB-C hubs, or docking stations with video output.
- Convert USB-A Ports to USB-C: Designed to connect USB-C earphones, cables, flash drives, card readers, and other USB-C accessories to standard USB-A ports. Plug-and-play with no drivers or software required.
- Aluminum Alloy Housing: Built with a sturdy aluminum alloy shell that aids in heat dissipation and protects against daily wear and scratches. Designed to maintain a stable and secure connection.
- Compact & Travel-Friendly: The ultra-compact design allows the adapter to stay plugged into your device without blocking adjacent ports or adding bulk, reducing wear and tear on your original USB ports.
- 12-Month Warranty: Backed by a 12-month manufacturer warranty for peace of mind. Designed to meet strict quality control standards for reliable everyday performance.
connect() failed (111: Connection refused) while connecting to upstream, client: 203.0.113.20, server: example.test, request: "GET /api HTTP/1.1", upstream: "http://127.0.0.1:8080/api"The upstream: field is the most useful clue. It gives you the protocol, host, port, and often the request path that failed. Copy the address exactly; do not test a different hostname or a port remembered from an older deployment.
Refused versus timed out
| Error | What happened | Most likely direction |
|---|---|---|
| 111, Connection refused | The target path responded with an active refusal because no permitted listener accepted the connection. | Stopped service, wrong port, wrong bind address, local topology error, or an explicit reject policy. |
| 110, Connection timed out | Connection establishment received no response before the timeout. | Packets dropped, unreachable host, routing problem, security policy silently discarding traffic, or an overloaded destination. |
These errors need different investigations. Increasing proxy_connect_timeout does not make a closed port start listening, and restarting NGINX does not repair a missing route.
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 minuteWindows 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 reinstallWhy clients see HTTP 502
NGINX is the server the client contacted, but it is also a client of the upstream application. If NGINX cannot establish that second connection, it has no valid upstream response to return. It therefore commonly sends a 502 response. The status describes the proxy-to-backend failure; it does not prove that the public-facing NGINX process is down.
A 502 can have other causes, so use the timestamp, virtual host, request, and upstream: address in the error log to confirm that error 111 is the underlying event. In an upstream group, one peer may refuse while another succeeds, so only requests assigned to the failed peer may show the problem.
Fast diagnostic sequence
Run these checks in order. They separate configuration syntax, application state, socket ownership, network reachability, and policy problems without guessing.
- Capture the exact log entry. Record the timestamp, the virtual host, request, protocol, and complete
upstream:value. If the line names127.0.0.1:8080, test that address and port, not a service name or a different machine. - Validate the loaded NGINX configuration. Run
nginx -t. A successful result proves that the configuration parses; it does not prove that an upstream is running or reachable. To inspect the complete configuration NGINX has loaded, runnginx -Tand search for every relevantproxy_pass,fastcgi_pass,uwsgi_pass,scgi_pass,memcached_pass, or streamupstreamentry. - Check the backend listener. On the backend host, run
ss -tlnp. Confirm that the expected process owns the expected port and that the local address is reachable from NGINX. A process can be running while listening on a different port or only on a loopback address. - Test from NGINX’s network namespace. Run
nc -zv <host> <port>from the NGINX host. In a container, execute the test inside the NGINX container; the host’s network namespace may have different routes and interfaces. If netcat is unavailable, an equivalent/dev/tcpcheck can test TCP reachability. - Check the application protocol. For an HTTP backend, a successful TCP connection is only the first step; use a request such as
curl -v http://<host>:<port>/healthif the service provides a health endpoint. For FastCGI, uWSGI, SCGI, memcached, or stream traffic, test with the protocol’s own client or a known-good application request. - Inspect policy controls. Check the backend host firewall, cloud security group, network ACL, Kubernetes NetworkPolicy, and any service-level allowlist. The rule must permit the NGINX source address and the actual destination port.
- Resolve address-family ambiguity. If the configuration uses
localhost, test both IPv4 and IPv6 explicitly. Replace the name with127.0.0.1or an explicit IPv6 address when that is the intended listener. - Review repeated failures and peer state. For an upstream group, determine whether one peer is consistently refusing, whether passive health checks have marked it unavailable, and whether another peer is serving requests. A healthy peer can hide a broken deployment until traffic is redistributed.
Check whether the backend is actually listening
Service stopped, crashed, or killed
First inspect the service manager, container status, pod status, and recent application logs. Look for a crash, failed startup dependency, configuration error, deployment race, or out-of-memory kill. Start or repair the service only after identifying why it stopped; repeatedly restarting a process can conceal a deterministic failure and create an outage loop.
Rank #2
- 5-in-1 USB-C Hub: Experience comprehensive connectivity featuring a Power Delivery input, two USB-A 2.0 ports, a USB-A 3.0 port, and an HDMI port. (Note: The USB-C power delivery input port is only for connecting an external wall charger to power your laptop and cannot power peripheral devices.)
- 90W Pass-Through Charging: Achieve optimal charging with 90W pass-through power to your laptop, supported by a total input of 100W, with the hub reserving 10W for operational efficiency. (Note: Wall charger not included.)
- Quick Data Transfers: Accelerate your productivity with rapid data transfers using a high-speed 5Gbps USB 3.0 port and two 480Mbps USB 2.0 ports.
- 4K HDMI Display: Enhance your visual experience with a hub capable of delivering 4K resolution at 30Hz in both mirror and extend modes. Please note that this hub is compatible with MacBook (macOS 12 and newer), Windows 10 and 11, ChromeOS, and laptops equipped with DP Alt Mode and Power Delivery. Note: This device is not compatible with Linux.
- What You Get: Anker USB-C Hub (5-in-1, 4K HDMI), welcome guide, 18-month warranty, and our friendly customer service.
After the service starts, repeat ss -tlnp and a direct TCP test. A green process status is not sufficient evidence: the application may have exited after the status check, may have failed to bind its port, or may be listening on a port different from the one in NGINX.
Wrong port or interface
Compare three values: the application’s configured listen port, the socket shown by ss -tlnp, and the port in the loaded NGINX configuration. They must match. Also compare the bind address:
127.0.0.1:8080accepts only local IPv4 connections on that host.[::1]:8080accepts only local IPv6 connections unless the operating system is configured for dual-stack behavior.0.0.0.0:8080listens on all IPv4 interfaces, subject to firewall rules.[::]:8080listens on IPv6 interfaces and may or may not accept IPv4, depending on the system’s dual-stack setting.
If NGINX runs on another host or in another container, a loopback-only backend is not reachable from it. Bind the application to a routable interface, or place NGINX where the loopback address is genuinely shared, then restrict exposure with firewall rules rather than assuming localhost means the same thing everywhere.
Fixes by deployment topology
NGINX and the application on the same host
Use an explicit loopback address only when both processes share the host network namespace. Confirm the listener with ss -tlnp, correct the port in the NGINX directive, and test locally:
curl -v http://127.0.0.1:8080/health
nc -zv 127.0.0.1 8080If the application listens on IPv6 only, use its IPv6 address in the upstream or configure it to listen on IPv4 as well. If the service is managed by a socket-activated unit, verify that the expected socket unit is active and that NGINX is targeting that socket’s port.
NGINX and the backend on different hosts
Replace loopback addresses with the backend host’s reachable private address or resolvable hostname. Confirm routing from the NGINX machine, then permit the NGINX source address on the backend firewall and cloud security group. Do not open the backend port to the entire internet merely to make a test pass; use the smallest source range required.
Rank #3
- Sleek 7-in-1 USB-C Hub: Features an HDMI port, two USB-A 3.0 ports, and a USB-C data port, each providing 5Gbps transfer speeds. It also includes a USB-C PD input port for charging up to 100W and dual SD and TF card slots, all in a compact design.
- Flawless 4K@60Hz Video with HDMI: Delivers exceptional clarity and smoothness with its 4K@60Hz HDMI port, making it ideal for high-definition presentations and entertainment. (Note: Only the HDMI port supports video projection; the USB-C port is for data transfer only.)
- Double Up on Efficiency: The two USB-A 3.0 ports and a USB-C port support a fast 5Gbps data rate, significantly boosting your transfer speeds and improving productivity.
- Fast and Reliable 85W Charging: Offers high-capacity, speedy charging for laptops up to 85W, so you spend less time tethered to an outlet and more time being productive.
- What You Get: Anker USB-C Hub (7-in-1), welcome guide, 18-month warranty, and our friendly customer service.
DNS can add another failure mode. Verify that the name resolves to the intended address from the NGINX host, and check whether a stale record points to an old instance. If DNS returns both address families, test each result and ensure the backend listens on every address that clients may select.
Docker and Compose
Inside a container, 127.0.0.1 and localhost refer to that container’s own network namespace. They do not refer to a sibling application container or automatically refer to the Docker host. This is the most common topology mistake behind a refusal that disappears when tested on the host.
Free tools Windows power users keep installed
One-click scans. No signup required.
Put the NGINX and application services on a shared Docker network and use the Compose service name as the upstream hostname, with the container’s listening port:
upstream app_backend {
server app:8080;
}
server {
location / {
proxy_pass http://app_backend;
}
}The published host port is used for host-to-container traffic; it is not necessarily the port another container should use. Check network membership, service-name resolution, container health, and the application bind address. A backend bound only to a loopback interface inside its own container cannot accept traffic arriving through the container network interface.
Kubernetes
Use the Kubernetes Service DNS name and service port rather than localhost. A typical in-cluster destination is the Service name and port, while the target pod may listen on a different container port. Verify the Endpoints or EndpointSlices, pod readiness, and that the Service selector actually matches the intended pods.
Test from the NGINX pod’s network namespace with a temporary diagnostic container or an available shell. Check NetworkPolicy rules in both directions, because a policy may permit ingress to the pod from one namespace but deny the NGINX namespace. If the Service has no ready endpoints, DNS can resolve correctly while the connection still fails or is routed nowhere useful.
Rank #4
- Dual Converters, Infinite Potential：Includes 2× USB C male to USB A female adapters and 2× USB A male to USB C female adapters. Perfect for a wide range of uses—tablets with Bluetooth keyboards, expand USB ports on macbook, and more. Two different converters for all your daily needs
- Next-Level 10Gbps & 3A Charging: No more slow 480Mbps, this usb to usb c adapter has a transfer speed of up to 10Gbps, allowing you to do more transferring in less time. This usb adapter fits both USB A and USB C charger, supporting up to 3A fast charging
- Upgraded Exquisite Craftsmanship: With an aluminum alloy housing and metal connector, the usbc to usb adapter is extremely durable and sturdy. Rigorously tested to withstand more than 10,000 times of plugging and unplugging, ensuring long-lasting performance
- Broad Compatible: The usb c to usb adapter widely supports all USB C/ USB A devices like laptops, tablets, cellphones, car chargers, and phone chargers. Such as compatible with MacBook Pro/Air 2023/2022, Thunderbolt 4/3 Devices,Apple MagSafe Watch 9/8/7/SE/Ultra, iPad Pro 2022/2021, Samsung Galaxy S23/S20/S10, and iPhone 17/16/15 Pro. Plug and play
- Please Note: To reach 10Gbps speed, keep the cable under 3.3 ft. For USB A Male to USB C adapters, try flipping the USB C connector. USB C Male to USB A adapters support bidirectional 10Gbps transfer within 3.3 ft
Resolve localhost and IPv4/IPv6 mismatches
On many systems, localhost resolves to both 127.0.0.1 and ::1, and the resolver may try IPv6 first. If the application listens only on IPv4, an NGINX upstream that resolves localhost to ::1 can fail even though curl http://127.0.0.1:8080 works.
Test each family explicitly:
nc -zv 127.0.0.1 8080
nc -zv ::1 8080
curl -4 -v http://localhost:8080/health
curl -6 -v http://localhost:8080/healthThen remove the ambiguity. Use 127.0.0.1 when the backend is intentionally IPv4-only, use an explicit IPv6 literal in brackets where appropriate, or configure the application and NGINX to support the same address families. Make sure the chosen literal matches the namespace in which NGINX runs.
Verify the NGINX directive and upstream protocol
HTTP reverse proxying
For HTTP applications, NGINX uses proxy_pass with a hostname or IP and an optional port. A typo in the port, hostname, or scheme sends traffic to a socket that may not exist. The presence of a URI in proxy_pass also changes the URI portion forwarded upstream, so inspect the complete directive when an application appears reachable but receives an unexpected path.
location /api/ {
proxy_pass http://127.0.0.1:8080;
}After editing, run nginx -t, then reload only after syntax passes. Check the error log again and confirm that the new upstream: value is the one you intended.
FastCGI, uWSGI, SCGI, and memcached
These protocols require their matching directives: fastcgi_pass, uwsgi_pass, scgi_pass, and memcached_pass. Pointing a directive at the wrong port or using an HTTP proxy directive for a non-HTTP listener can produce a refusal or a protocol failure. Confirm the application server’s protocol, socket type, address, and port before changing NGINX.
TCP and stream proxying
For TCP proxying, NGINX’s stream configuration uses an upstream group whose server entries include a port:
Best Value
- 5-in-1 Connectivity: Equipped with a 4K HDMI port, a 5 Gbps USB-C data port, two 5 Gbps USB-A ports, and a USB C 100W PD-IN port. Note: The USB C 100W PD-IN port supports only charging and does not support data transfer devices such as headphones or speakers.
- Powerful Pass-Through Charging: Supports up to 85W pass-through charging so you can power up your laptop while you use the hub. Note: Pass-through charging requires a charger (not included). Note: To achieve full power for iPad, we recommend using a 45W wall charger.
- Transfer Files in Seconds: Move files to and from your laptop at speeds of up to 5 Gbps via the USB-C and USB-A data ports. Note: The USB C 5Gbps Data port does not support video output.
- HD Display: Connect to the HDMI port to stream or mirror content to an external monitor in resolutions of up to 4K@30Hz. Note: The USB-C ports do not support video output.
- What You Get: Anker 332 USB-C Hub (5-in-1), welcome guide, our worry-free 18-month warranty, and friendly customer service.
stream {
upstream database_backend {
server 10.0.20.15:5432;
}
server {
listen 5432;
proxy_pass database_backend;
proxy_connect_timeout 5s;
}
}A missing or stale port is enough to cause error 111. The proxy_connect_timeout setting controls how long connection establishment is attempted; it does not make an unavailable listener healthy. If the upstream accepts traffic only from a particular source interface, proxy_bind can select that source address, provided routing and policy allow it.
Firewall, ACL, security-group, and network-policy checks
A firewall can actively reject a connection, silently drop it, or allow the TCP handshake while a host-level service denies the application. Check the policy on the path, not only on the NGINX server:
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →- On the backend host, inspect host-firewall rules and the service’s own allowlist.
- In a cloud network, verify security-group ingress on the backend port and any subnet or network ACL rules.
- In Kubernetes, inspect NetworkPolicy selectors, namespaces, ports, and both ingress and egress directions.
- Confirm that the NGINX source address is the one policies see; NAT, proxies, and container networks can change it.
After a rule change, repeat the direct TCP test from NGINX’s actual network namespace and then issue a real application request. A successful test from an administrator workstation does not prove that the NGINX source is permitted.
Upstream groups, health, and retries
NGINX upstream groups provide named peers, server ports, round-robin distribution, and passive health behavior. With several peers, a connection failure can be retried on another peer, so users may see intermittent success while one backend is down. With only one peer, there is no alternate destination and the request generally returns 502 immediately.
Use multiple peers for availability, but do not treat retries as a repair for a consistently closed port. Repeated retries increase latency and can amplify load during an outage. Investigate the failed peer, its deployment state, and its health-check results. Remove or quarantine a peer only as an operational mitigation, then restore it after the listener and application have been fixed.
Common symptoms and the right fix
| Symptom | Likely cause | Useful confirmation |
|---|---|---|
| Every request returns 502 immediately | Single backend is stopped, wrong port, or wrong bind address. | ss -tlnp and nc -zv from NGINX. |
| Works with curl on the host but not through a containerized NGINX | Container-local localhost or different network namespace. |
Run the same TCP test inside the NGINX container; use the service name. |
| Only IPv6 requests fail | Backend listens on IPv4 only, or IPv6 policy blocks the port. | Compare curl -4 and curl -6; inspect listeners. |
| Failures began after a deployment | Port, readiness, bind address, or service-discovery value changed. | Compare the deployed configuration with nginx -T and current endpoints. |
| Some requests fail while others succeed | One peer in an upstream group is unavailable. | Map log entries to each peer and inspect passive health state. |
| Direct TCP connection times out rather than refuses | Route or policy is dropping traffic instead of rejecting it. | Check security groups, ACLs, NetworkPolicy, and routing from NGINX. |
Apply a safe configuration change
- Edit the smallest possible upstream, listener, or address value.
- Run
nginx -tand correct every reported error. - Review
nginx -Tto ensure the active server block is the one you changed, especially when includes or multiple virtual hosts are present. - Reload NGINX with the service manager’s reload operation rather than stopping it unnecessarily.
- Repeat the direct TCP and protocol-level test, then send a real request through NGINX.
- Watch the error log for the same timestamp and confirm that error 111 has stopped for the intended upstream.
Keep the previous configuration available for rollback. If a change fixes the refusal but produces application errors, restore the known-good file and investigate the backend protocol or URI separately.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsPrevention checklist
- Declare backend ports and bind addresses in one deployment configuration source, then render NGINX from that source where practical.
- Use service discovery names for container and Kubernetes traffic; reserve loopback addresses for processes that truly share a network namespace.
- Add readiness checks that verify the application can accept the protocol NGINX will use, not merely that a process exists.
- Alert on repeated upstream connection failures and distinguish error 111 from connection timeouts.
- Document firewall, security-group, and NetworkPolicy ownership for every backend port.
- Test both IPv4 and IPv6 when DNS publishes both families.
- Keep more than one upstream peer when the application supports it, while monitoring each peer individually.
- Validate with
nginx -tin deployment pipelines before a reload.
When to escalate
Escalate to the application owner when the process repeatedly crashes, fails to bind, or reports an out-of-memory kill. Escalate to the network or platform owner when the listener is correct but the direct test from NGINX is blocked by routing, security groups, ACLs, or NetworkPolicy. Provide the exact log line, source namespace or host, destination address and port, listener output, configuration test result, and direct-test output so the next person can reproduce the failure without guessing.
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.
