Stunnel客户端连接偶发中断求助（含配置与错误日志）

Let’s start by demystifying that SSL alert you’re seeing: SSL alert (read): warning: close notify is not an error—it’s a standard, graceful shutdown signal defined in the TLS protocol. This means the remote server (x.y.z.w:nnnn) initiated a clean closure of the TLS connection. The problem here isn’t the alert itself, but why it’s happening every 2-3 weeks after hours of runtime.

Possible Root Causes #

Here are the most likely reasons the remote server is closing your connection:

• Remote Server Idle Timeout: Most servers enforce a timeout for connections that sit idle without data transfer. If your application doesn’t send traffic regularly over the stunnel link, the remote server may flag it as inactive and close it after a set period.
• TLS Session Duration Limits: Some servers cap the maximum lifetime of a TLS session, even if there’s ongoing traffic. Once this limit is hit, the server will send a close notify to terminate the old session.
• Network Fluctuations: While less likely (since the alert is graceful), intermittent network blips could trigger the server to initiate a clean shutdown if it detects instability.
• Stunnel Configuration Gaps: Default stunnel settings might not account for long-lived connections, leading to unexpected closures if no keepalive or reconnection logic is in place.

Troubleshooting Steps to Narrow It Down #

1. Check with the Remote Server Team: Reach out to the company running x.y.z.w:nnnn and ask if their server enforces connection idle timeouts or TLS session limits. This is the fastest way to get definitive answers.
2. Crank Up Stunnel Logging: Your existing logs have LOG7 entries, but ensure your stunnel config has debug = 7 enabled to capture detailed traffic flow. Look for entries immediately before the close notify—this will tell you if the connection was idle or actively transferring data when the shutdown was initiated.
3. Capture Network Traffic: Use tcpdump or Wireshark to record traffic between your stunnel instance and the remote server. Analyzing the capture will confirm if keepalive packets are being sent, and whether the shutdown happens during idle periods.
4. Test TCP Keepalives: Add these lines to your stunnel config to keep the connection active, preventing idle timeouts:

   keepalive = yes
   keepidle = 300  # Send keepalive after 5 minutes of inactivity
   keepintvl = 60  # Retry keepalive every 60 seconds
   keepcnt = 5     # Give up after 5 failed keepalives
   

   This ensures the server sees regular traffic even when your application isn’t sending data.
5. Enable TLS Session Renegotiation: If the issue is TLS session expiry, add renegotiation = secure to your stunnel config. This tells stunnel to safely renegotiate the TLS session before the remote server’s limit is hit, avoiding a forced shutdown.

Permanent Fixes to Implement #

• Enforce TCP Keepalives: This is the most common fix for idle-related closures. The config snippet above should keep the connection alive through periods of inactivity.
• Ensure Automatic Reconnection: Verify that your application automatically reconnects to stunnel’s 9998 port if the connection drops. Stunnel itself usually handles reconnection to the remote server by default, but double-check your config for retry = yes to be safe.
• Align with Remote Server Limits: If the remote team shares their timeout values, adjust your stunnel keepalive or renegotiation settings to match (e.g., set keepidle to a value lower than their idle timeout).

内容的提问来源于stack exchange，提问作者GoodToLearn