首页 Function Compute Function Compute FAQ Code development Custom Container FAQ 502 error: "Process exited unexpectedly before completing request"

502 error: "Process exited unexpectedly before completing request"

更新时间: 2026-06-23 10:59:30

In Custom Container runtimes, the HTTP server process terminates before Function Compute receives a complete response. Either the HTTP server closes the connection prematurely, or the process crashes due to an unhandled exception or explicit exit call.

Check function logs first to determine which cause applies, then follow the corresponding fix.

Cause 1: HTTP server closed the connection

Function Compute maintains a persistent keep-alive connection to the HTTP server in a Custom Container runtime. If the server closes this connection, Function Compute loses its communication channel to the container.

This typically happens when:

  • Keep-alive is not enabled on the HTTP server.

  • The HTTP server closes idle connections after a timeout shorter than 15 minutes.

  • A read/write operation times out or returns an error, causing the server to drop the connection.

How Function Compute handles connection failures:

Request type HTTP methods Behavior on connection failure
Idempotent GET, HEAD, OPTIONS, TRACE Function Compute retries the request automatically
Non-idempotent POST, PATCH Function Compute returns a 502 error without retrying

Because non-idempotent requests are not retried, proper keep-alive configuration prevents 502 errors on POST and PATCH requests.

Fix: configure keep-alive and idle timeout

Apply both settings on the HTTP server running inside the custom container:

  1. Enable keep-alive mode on the HTTP server.

  2. Disable idle timeout, or set it to more than 15 minutes. Function Compute may reuse connections after long idle periods. If the server closes the connection before Function Compute sends the next request, the connection is lost.

The exact configuration depends on the HTTP server framework. The following examples cover common frameworks.

Go (GoFrame)

s := g.Server()
// Disable idle timeout to prevent the server from closing keep-alive connections
s.SetIdleTimeout(0)
// ReadTimeout defaults to 60s; adjust if needed for long-running requests

Python (Uvicorn)

# Set --timeout-keep-alive to a value greater than 900 seconds (15 minutes)
uvicorn app:app --host 0.0.0.0 --port 9000 --timeout-keep-alive 920

Node.js (Express / HTTP)

const server = app.listen(9000, '0.0.0.0');
// Set keepAliveTimeout to a value greater than 900000 ms (15 minutes)
server.keepAliveTimeout = 920000;
server.headersTimeout = 940000;

Verify the fix

After deploying the updated configuration, send a few requests with pauses of several minutes between them to simulate sparse invocations. Confirm that no EOF or connection reset by peer errors appear in the function logs.

Cause 2: process crashed unexpectedly

The container process exited before completing the request. This is a code-level issue, not a connection configuration issue.

Common causes:

  • The code calls an explicit exit operation (for example, os.Exit() in Go, sys.exit() in Python, or process.exit() in Node.js).

  • An uncaught exception terminates the process.

Fix: remove exit calls and add top-level exception handling

  1. Check for explicit exit calls. Search the codebase for exit operations (exit, os.Exit, sys.exit, process.exit). Remove any that run during request handling, or replace them with error responses.

  2. Add top-level exception handling. Wrap the request handler in a try-catch block so that uncaught exceptions return an error response instead of crashing the process.

    Python (Flask)

    @app.errorhandler(Exception)
    def handle_exception(e):
        # Log the error and return a 500 response instead of crashing
        app.logger.error(f"Unhandled exception: {e}", exc_info=True)
        return {"error": "Internal server error"}, 500

    Node.js

    // Catch unhandled exceptions to prevent the process from exiting
    process.on('uncaughtException', (err) => {
        console.error('Uncaught exception:', err);
    });
    
    process.on('unhandledRejection', (reason) => {
        console.error('Unhandled rejection:', reason);
    });

Verify the fix

After deploying the fix, invoke the function with the same input that previously triggered the 502 error. Confirm that the function returns a valid response (even if it is an error response) instead of a 502.

Diagnostic checklist

If the cause is unclear, work through this checklist:

  1. Check function logs. Look for EOF, connection reset by peer, or exception stack traces.

    • Connection-related errors point to Cause 1.

    • Exception stack traces or exit signals point to Cause 2.

  2. Check whether the error correlates with idle time. If 502 errors appear after periods of no traffic (sparse invocations), the HTTP server is likely closing idle connections. See Cause 1.

  3. Check whether the error is consistent or intermittent.

    • Intermittent errors on POST/PATCH requests suggest a keep-alive or timeout misconfiguration.

    • Consistent errors on every request suggest a process crash.

上一篇: What do I do if my HTTP server fails to start within 120s? 下一篇: What do I do if a 404 error occurs when I use a browser or the cURL tool to access a function?
阿里云首页 函数计算 相关技术圈