nginx后端连接，nginx代理后端接口

nginx对tcp配置与客户端调用

Nginx对TCP的配置与客户端调用主要涉及安装Nginx、配置stream模块、客户端连接与请求转发等关键步骤。Nginx TCP配置：安装Nginx：在Linux系统上，通过包管理器安装Nginx，例如在Ubuntu上使用sudo apt update和sudo apt install nginx命令。

配置步骤 创建新的server块：在Nginx的配置文件中，添加一个新的server块。指定监听的外部端口和内部的后端服务器地址。设置proxy_pass指令：在server块内，使用proxy_pass指令将接收到的TCP请求转发到内部服务器的SSH端口。

当需要通过Nginx将外部流量转发到内部的SSH服务时，可能会遇到反向代理TCP协议的需求。这种情况下，我们需要配置Nginx以代理SSH端口，以便于客户端通过指定的外部端口（如22822）连接到vps上的SSH服务。实现这一目标的方法是通过Nginx的proxy_pass指令，将接收到的TCP请求转发到内部服务器的22端口。

变量 $proxy_add_x_forwarded_for 的值与 realIp 模块的配置无关，只与客户端是否传递 X-Forwarded-For 头字段和 $remote_addr 变量有关。 realIp 模块配置 nginx 获取客户端真实 IP，此 IP 放入 $remote_addr 变量。 nginx 首先从 TCP 连接获取 IP，认为此 IP 是客户端真实 IP。

客户端直接调用sendto函数并加上MSG_FAstopEN标志来连接服务器并发送数据；而未启用TFO时，则会先调用connect函数进行握手。小结 TCP快速打开是一种有效的网络优化技术，可以降低连接建立的延迟并提高网络应用的性能。通过理解TFO的工作原理和配置方法，可以更好地利用这一技术来优化网络应用。

当客户端通过代理服务器访问隐藏了真实IP的数据库或进行HTTP/HTTPS和tcp/udp协议通信时，proxy protocol能确保我们看到的是实际客户端的数据。启用proxy protocol非常直观，只需在listen配置中添加proxy_protocol。Nginx自带的Real-IP模块能进一步重写$remote_addr和$remote_port，提供原始客户端信息。

生产Nginx现大量TIME-wait,连接耗尽,该如何处理?

1、增大端口范围：在linux系统中，可以通过调整/proc/sys/net/ipv4/ip_local_port_range来增加可用的本地端口数量，从而缓解端口耗尽的问题。调整TCP连接的MSL值：虽然MSL值通常固定为2分钟，但在某些情况下，可以考虑调整相关参数来缩短TIME_WAIT状态的时间。

2、服务器端一般设置不允许主动关闭连接，但HTTP请求中，http头部connection参数可能设置为close，则服务端处理完请求会主动关闭TCP连接。Nginx反向代理场景中，可能出现大量短链接，服务器端可能存在大量TIME_WAIT状态。

3、尽管排除了网络和中间件问题，但发现web前端nginx对API的大量请求可能是问题源头。通过IP地址和请求频率，缩小范围至特定容器。深入代码层面排查：确定问题容器：发现可能是主项目中的apacheapi容器由于循环请求API并频繁断开连接，导致TIME_WAIT状态持续生成。

4、spring Cloud网关连接后端产生大量TIME_WAIT状态的问题，可以通过修改TCP/IP的内核参数、使用长连接以及配置Nginx的Keepalive等方式进行解决。

5、分析问题时，首先关注了模拟高并发场景下的情况。在短期内，大量TIME_WAIT状态的TCP连接会显现，但很快，这些连接被回收，服务恢复正常运行。在实际业务场景中，持续的高并发状态下，大量TIME_WAIT状态连接存在，属于正常现象。

6、通过分析容器IP和连接信息，发现API项目后端是被请求最多的，且大部分TIME_WAIT状态的TCP连接与nginx有关。尽管排除了网络和中间件问题，但Web前端nginx对API的大量请求可能导致问题。191641这个IP（可能是容器网关）频繁发起请求，但具体是哪个容器发出的还无法确定。

后端写响应给nginxconnectionreset

后端写响应给nginxconnectionreset由以下几个原因引起：后端服务器负载过重或处理能力不足，导致连接超时或重置。后端服务器的防火墙或安全策略阻止了与Nginx的正常通信，需要进行相应的配置更改。网络中存在问题，如网络故障或传输错误，导致连接中断。

查看错误日志 首先，需要查看Nginx的错误日志。错误日志中通常会记录“Connection reset by peer”的详细信息，包括发生错误的客户端IP、服务器IP以及请求的资源等。这些信息是诊断问题的关键。 分析错误原因 错误原因可能包括：上游服务器已经关闭了连接，但Nginx还在尝试读取或写入数据。

前段时间公司的一个项目出现了一个 BUG，使用 ajax 上传大文件时会出现网络问题。使用 chrome 开发者工具查看网络请求时，发现错误是 ERR_CONNECTION_RESET 。看到这个错误就想到访问 google 出现的情况， 哈哈。然后用 IE 的开发人员工具查看网络请求，显示的错误码是 403。

它是TCP包头中的一个标志位，在收到置这个标志位的数据包后，连接就会被关闭，此时接收到 RST的一方，在应用层会看到一个 connection reset 或 connection refused的报错。 图源：互联网 而之所以发出RST报文，一般有两个常见原因。