MCP Connection Issues: Why My MCP Server Kept Dropping Connections and How I Fixed It (After 86 Production Outages)

Honestly, I thought I had everything figured out after 86 outages. Logging was done. Health checks were in place. Tool discovery had fuzzy matching. Authentication handled every possible location. Rate limiting was working.

But my MCP server kept dropping connections randomly.

Three days of debugging later, I found the problem — and it wasn't what I expected. It was all about SSE (Server-Sent Events) streaming. If you're building an MCP server, you need to read this. I saved you three days of headache.

The Problem: Random Connection Drops

Let me set the scene. My MCP server has been running in production for a while. Everything works fine most of the time. But randomly, clients would get disconnected mid-request. Sometimes it happened after 30 seconds. Sometimes after 2 minutes. Sometimes it worked perfectly.

The worst part? It only happened in production. Locally, everything worked fine. Classic "it works on my machine" situation.

Here's what the error looked like from the client side:

Error: disconnected before response completed

That's it. No additional info. Just ... disconnected.

My First Guesses (All Wrong)

Like any good developer, I started blaming the usual suspects:

1. Reverse proxy timeout – I checked Nginx settings. Increased timeouts. Restarted. Still happening.
2. Cloudflare idle timeout – Cloudflare has a 100-second idle timeout. But it was happening faster than that sometimes. Still, I checked. Didn't help.
3. Memory leak – Profiled the app. Memory was stable. No leak.
4. Thread deadlock – Looked at thread dumps. Nothing blocked. Everything looked normal.
5. Database connection issues – Database connection pool was fine. Connections checked out fine.

I spent half a day going through this list. Nothing worked. The problem kept happening.

The Breakthrough: It's the SSE, Stupid

MCP uses SSE for the connection from server to client. The client sends the JSON-RPC request over HTTP POST, and the server streams responses back via SSE.

Here's what I missed: SSE connections are idle connections. If nothing is being sent, some proxies/load balancers will drop them.

Wait, but how long is idle? Depends on your hosting. On Fly.io, the default idle timeout is 75 seconds. On Cloudflare, it's 100 seconds. On Heroku, it's 55 seconds.

And here's the thing about MCP: most of the time, the connection is idle. The client connects, waits for the LLM to process the request, then the server sends the response. If the LLM takes more than your proxy's idle timeout ... boom. Connection dropped.

I know, I know. You're thinking "just increase the timeout." But you can't always do that. Some platforms don't let you change it. And even if you can, what if the LLM is processing a really big request that takes 5 minutes? You can't just set the timeout to 10 minutes – that creates other problems.

The Solution: Heartbeat Comments

SSE allows any comment line starting with : to be sent as a heartbeat. These comments don't interrupt the actual event stream, they just keep the connection alive.

Here's what it looks like on the wire:

: heartbeat
data: {"jsonrpc":"2.0","method":"tools/list","result":{"tools":[...]}

: heartbeat
: heartbeat
data: {"jsonrpc":"2.0","method":"tools/call","result":{"content":[...]}

The client just ignores the comment lines. But they count as activity, so the proxy doesn't drop the connection.

Brilliant, right? Simple, effective, almost no code.

Implementation in Java/Spring Boot

I'm building my MCP server with Java Spring Boot, so let me show you the complete implementation. It's about 30 lines of code.

First, the SSE emitter configuration with heartbeats:

import org.springframework.web.servlet.mvc.method.annotation.SseEmitter;
import java.io.IOException;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledFuture;
import java.util.concurrent.TimeUnit;

public class McpSseConnection {
    private final SseEmitter emitter;
    private final ScheduledExecutorService scheduler;
    private ScheduledFuture<?> heartbeatTask;
    private static final long HEARTBEAT_INTERVAL = 30; // seconds

    public McpSseConnection() {
        // Use 0 timeout because we handle heartbeats ourselves
        this.emitter = new SseEmitter(0L);
        this.scheduler = Executors.newSingleThreadScheduledExecutor();
        startHeartbeat();
    }

    private void startHeartbeat() {
        heartbeatTask = scheduler.scheduleAtFixedRate(() -> {
            try {
                // Send a comment heartbeat – this keeps the connection alive
                emitter.send(SseEmitter.event().comment("heartbeat"));
            } catch (IOException e) {
                // Connection closed, stop heartbeats
                heartbeatTask.cancel(false);
                scheduler.shutdown();
            }
        }, HEARTBEAT_INTERVAL, HEARTBEAT_INTERVAL, TimeUnit.SECONDS);
    }

    public SseEmitter getEmitter() {
        return emitter;
    }

    public void complete() {
        heartbeatTask.cancel(false);
        scheduler.shutdown();
        emitter.complete();
    }

    public void completeWithError(Throwable ex) {
        heartbeatTask.cancel(false);
        scheduler.shutdown();
        emitter.completeWithError(ex);
    }
}

Then in your controller, use it like this:

import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.servlet.mvc.method.annotation.SseEmitter;

@RestController
public class McpController {

    @PostMapping(value = "/mcp/messages", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public SseEmitter handleMessages() {
        McpSseConnection connection = new McpSseConnection();
        SseEmitter emitter = connection.getEmitter();

        // Process the MCP request asynchronously
        mcpMessageProcessor.process(request, emitter)
            .whenComplete((result, error) -> {
                if (error != null) {
                    connection.completeWithError(error);
                } else {
                    connection.complete();
                }
            });

        return emitter;
    }
}

That's it. Thirty lines of code. Problem solved.

What About CORS?

Oh right, you're going to hit CORS preflight issues with SSE too. Let me save you another hour. Make sure your CORS configuration allows OPTIONS for the SSE endpoint and doesn't require auth for preflight:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;

@Configuration
public class CorsConfig {

    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.setAllowCredentials(true);
        config.addAllowedOriginPattern("*"); // customize for your domains
        config.addAllowedHeader("*");
        config.addAllowedMethod("*");
        // Allow preflight to be cached for 1 hour
        config.setMaxAge(3600L);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

The key point: don't require authentication for OPTIONS requests. Most proxies and browsers expect OPTIONS to be unauthenticated. If you require auth on OPTIONS, preflight will fail before the connection even starts.

What About proxy buffering?

Another gotcha! If you're using Nginx in front of your server, turn off proxy buffering for SSE endpoints:

location /mcp/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    proxy_chunked_transfer_encoding on;
    proxy_buffering off;
    proxy_cache off;
}

If you leave proxy buffering on, Nginx will buffer the entire response before sending it to the client. That means no streaming – the client waits until everything is done. Which defeats the whole purpose of SSE streaming.

I learned this the hard way. Everything looked fine locally, but on production with Nginx, nothing worked until I added these settings.

Pros & Cons of This Approach

Let me be honest with you – this isn't perfect. Nothing is. Here's what works and what doesn't.

Pros

Cons

When Should You Use This?

Use this approach if:

• You're building a personal MCP server or small-scale service
• Most requests complete within a few minutes
• You don't want to mess with websockets
• Your hosting provider has aggressive idle timeouts

Consider websockets instead if:

• You need bidirectional communication
• You expect long-lived connections (hours)
• You have high traffic and want better connection multiplexing

Honestly, for most personal MCP servers, this approach is perfect. It's simple, it works, and you can implement it in 10 minutes. I've been running it for a month now – zero dropped connections since deploying.

What I Learned

After 86 outages and three days of debugging, here's what I'll remember:

1. SSE connections are idle connections – if you expect pauses, send heartbeats. Period.
2. Proxies exist to drop your connections – it's not personal, it's their job. Don't give them a reason.
3. Local ≠ production – your proxy will break things that work fine locally. Test early.
4. Simple solutions beat complex ones – heartbeats are simpler than websockets for this use case.
5. Document your proxy config – I'm putting this in my repo README so the next person (me) doesn't spend three days debugging this again.

Your Turn

Have you built an MCP server? Did you run into connection dropping issues? Did you find a different solution? I'd love to hear about it in the comments.

And if this saved you three days of debugging – drop a ❤️! It helps other people find this article.

Check out the full implementation on GitHub: kevinten10/Papers – it's open source and you can copy-paste the heartbeat code directly into your own project.