Ollama Connection Timeout? Fix 60-Second Issues With Open WebUI

Understanding the Frustrating Ollama 60-Second Timeout

Hey everyone! Ever been in that super frustrating situation where you're trying to get your large language model (LLM) to spit out some awesome code or a detailed explanation, only for your Ollama connection to time out after exactly 60 seconds? Yeah, it's a real buzzkill, especially when you're working with powerful models like codellama:70b through Open WebUI. You know the model is still chugging along, doing its thing in the background, but the connection just… drops. It feels like hitting a brick wall, right? This isn't just a minor annoyance; it can seriously halt your development workflow and make what should be an exciting interaction with AI feel like a constant battle against the clock. When you’re relying on these sophisticated LLMs for complex tasks, whether it’s generating extensive code blocks, drafting long-form content, or tackling intricate problem-solving, a premature connection closure is simply unacceptable. We invest time and resources into setting up these environments, expecting them to handle the computational demands without flinching. The expectation is that the system should wait for completion or, at the very least, handle streaming responses gracefully, allowing the AI to deliver its full output. But instead, we're greeted with error messages like "ConnectionError: Request timeout after 60000ms" and "Model was still generating but connection closed." This particular Ollama connection timeout after a mere 60 seconds is a common pain point, especially within Docker environments where various layers of networking and proxying can introduce their own unseen limitations. It’s not just about a slow model; it's about the interface or proxy layer prematurely cutting off communication, even though Ollama itself is still working hard. This article is all about diving deep into why this happens and, more importantly, how to fix it, so you can get back to enjoying seamless interactions with your Ollama models via Open WebUI without that dreaded 60-second limit looming over your head. We're going to break down the common culprits and equip you with practical solutions to ensure your long-running requests finally complete without a hitch.

The Core Problem: Why Your Ollama Requests Time Out

Let's get straight to the core problem: you're encountering long-running Ollama requests that consistently hit a timeout wall after precisely 60 seconds. This isn't random; it's a very specific, hard-stop limit that many users, especially those leveraging Open WebUI with massive models like codellama:70b, are reporting. The frustrating part? Ollama itself often completes the request successfully on its backend, as evidenced in its logs. The issue isn't usually with the model's ability to generate; it's with the connection between Open WebUI and Ollama or an intermediary service dropping the ball. Imagine sending a complex coding question to codellama:70b, expecting a comprehensive answer, only to see your Open WebUI session error out after a minute, displaying ConnectionError: Request timeout after 60000ms and the ominous message, Model was still generating but connection closed. This scenario is exactly what we're trying to debug and resolve. This behavior has been observed across various setups, including Docker installations where Open WebUI v0.6.19 and Ollama v0.2.6 are running on operating systems like macOS Sonoma 14.1. The steps to reproduce this are alarmingly consistent: simply select a large model like codellama:70b, send it a complex coding question or any prompt that requires extensive generation, wait approximately 60 seconds, and boom – connection times out with an error. While you'd expect the request to wait for completion or at least leverage streaming to handle long responses gracefully, the actual behavior is an abrupt connection closure. Even the streaming mode experiences the same 60-second cutoff, which strongly suggests that the bottleneck isn't in how the data is being sent, but rather in a timeout somewhere along the connection path. The Docker logs clearly paint this picture: an INFO: Sending request to Ollama: codellama:70b is often followed exactly 60 seconds later by an ERROR: Ollama request timeout and ERROR: Connection closed before completion. This crucial detail, coupled with the fact that this only affects very large models (70b+), points away from a simple processing error within Ollama and towards a configuration oversight or an unforeseen default timeout within the network stack or the application itself. It's not just a codellama:70b problem, but a large model problem where the sheer time required for initial tokens or full responses exceeds a built-in, unconfigured 60-second timeout limit.

Diving Deep: Understanding the Timeout Mechanisms

When we're troubleshooting a persistent 60-second timeout issue, especially in a Docker environment involving Ollama and Open WebUI, it's essential to understand where these timeouts are typically configured. Many users, like the one in our example, have already tried to address this by setting environment variables such as OLLAMA_API_TIMEOUT and REQUEST_TIMEOUT to generous values, like 300000 milliseconds (which is 5 minutes!). Yet, despite these explicit configurations, the connection still closes after 60 seconds. This is the head-scratcher, guys. If you've explicitly told your system to wait for 5 minutes, but it's still timing out at 1 minute, it means there's another layer, another default, or another proxy somewhere in the chain that's enforcing its own, stricter timeout. Let's dissect the common players in this timeout game. Firstly, Open WebUI and Ollama themselves are designed with API timeout settings. OLLAMA_API_TIMEOUT is usually specific to the connection from Open WebUI to the Ollama server, dictating how long Open WebUI will wait for a response from Ollama. REQUEST_TIMEOUT, on the other hand, can be a more general setting, potentially governing the entire request lifecycle within Open WebUI or its underlying web server. The provided configuration snippet shows OLLAMA_BASE_URL=http://host.docker.internal:11434. This host.docker.internal is key in a Docker setup; it's how a container can reach the host machine. If Ollama is running directly on the host, this URL is correct. However, if Ollama is also in a Docker container, you'd typically use a Docker network alias or IP address. But for our current problem, assuming the OLLAMA_BASE_URL is correct, the issue isn't about reaching Ollama, but sustaining the connection. So, if your OLLAMA_API_TIMEOUT and REQUEST_TIMEOUT are both set to 300,000ms, and you're still seeing a 60,000ms timeout, where else could it be? This is where we need to hypothesize about other potential sources of a 60-second timeout. Could it be a reverse proxy? Many setups place Nginx, Caddy, or Traefik in front of Open WebUI for security, load balancing, or SSL termination. These proxies have their own default timeouts (e.g., proxy_read_timeout, proxy_send_timeout, proxy_connect_timeout), and a common default for proxy_read_timeout is indeed 60 seconds. If not explicitly configured, they will cut off long-running connections. Another less obvious culprit could be the client-side timeout in the browser or the frontend framework used by Open WebUI. While less common for such a precise 60-second server-side error, it's worth considering. Finally, there could be a hardcoded internal default timeout within Open WebUI's code that isn't overridden by the environment variables, or perhaps an issue with how those variables are being passed to the correct part of the application. Understanding these different layers is crucial for pinpointing and eliminating the elusive 60-second timeout.

Practical Solutions: How to Conquer the 60-Second Wall

Alright, it's time to roll up our sleeves and tackle this 60-second timeout head-on. If you're consistently hitting this wall with Open WebUI and Ollama, especially with large models, don't despair! Here are some practical solutions to help you fix Ollama timeout issues and ensure your long-running requests finally complete.

Solution 1: Verify Open WebUI Environment Variables Thoroughly

First things first, let's double-check those environment variables we talked about. While you might have set OLLAMA_API_TIMEOUT and REQUEST_TIMEOUT, it's crucial to ensure they are being picked up correctly by the Open WebUI container. This is often the most overlooked step. If you're using docker-compose.yml, your configuration should look something like this:

version: '3.8'
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    ports:
      - "8080:8080"
    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434
      - OLLAMA_API_TIMEOUT=300000 # 5 minutes
      - REQUEST_TIMEOUT=300000    # 5 minutes
      # Add other necessary variables here
    volumes:
      - ./open-webui-data:/app/backend/data
    restart: always

  ollama:
    image: ollama/ollama
    ports:
      - "11434:11434"
    volumes:
      - ./ollama-data:/root/.ollama
    restart: always

If you're using a docker run command, ensure you're using the -e flag correctly:

docker run -d --network=host -v open-webui:/app/backend/data -e OLLAMA_BASE_URL=http://host.docker.internal:11434 -e OLLAMA_API_TIMEOUT=300000 -e REQUEST_TIMEOUT=300000 --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Crucially, after making any changes to docker-compose.yml or your docker run command, you must restart your containers. For Docker Compose, run docker-compose down followed by docker-compose up -d. For standalone containers, docker stop <container_name> and docker rm <container_name> before running the new docker run command. Verify that these variables are indeed active inside the running container by exec'ing into it (docker exec -it <container_id> sh) and running env | grep OLLAMA or env | grep REQUEST.

Solution 2: Check for Hidden Proxies or Load Balancers

This is a major culprit for the 60-second timeout when explicitly set timeouts fail. If you have any reverse proxy like Nginx, Caddy, or Traefik sitting in front of your Open WebUI (or even directly in front of Ollama), it likely has its own default timeout that's overriding your application-level settings. Many of these proxies have a default proxy_read_timeout of 60 seconds. You need to explicitly configure them to handle longer connections. Here's an example for Nginx:

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://localhost:8080; # Or your Open WebUI container IP/port
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;

        # *** THESE ARE THE IMPORTANT TIMEOUT SETTINGS ***
        proxy_connect_timeout 300s; # How long to wait to connect to the backend
        proxy_send_timeout 300s;    # How long to wait for the backend to send data
        proxy_read_timeout 300s;    # How long to wait for a response from the backend
    }
}

Remember to reload your Nginx (or other proxy) configuration after making changes.

Solution 3: Inspect Open WebUI's Internal Defaults (Advanced)

If the above solutions don't work, and you're confident your environment variables are set correctly and no proxy is interfering, you might be looking at a hardcoded internal timeout within Open WebUI's codebase that isn't fully exposed to environment variables, or a bug in how it interprets them. This is less common but possible. You might need to delve into the Open WebUI source code or check their GitHub issues for similar reports. Alternatively, ensure you are on the latest stable version of Open WebUI, as such issues might be resolved in newer updates.

Solution 4: Consider the Network Layer

Briefly, ensure your Docker network configuration is robust. If Ollama and Open WebUI are in separate containers, verify they are on the same Docker network or properly linked. Occasional network bridge issues or misconfigurations can introduce latency or unexpected connection drops, though a precise 60-second timeout usually points to an explicit setting rather than general network flakiness. If Ollama and Open WebUI are meant to communicate via host.docker.internal, ensure the host's firewall isn't blocking the port.

Solution 5: Optimizing Model Usage (Workaround/Prevention)

While this doesn't fix the timeout itself, optimizing your model interaction can mitigate the impact. Ensure Ollama has sufficient resources (RAM, CPU cores) allocated to it, especially for a codellama:70b model, which is a resource hog. A slow-generating model can make timeout issues more apparent. For extremely complex prompts, if possible, consider chunking your requests into smaller, manageable parts, although this can compromise the seamless interaction of an AI chat. Also, always ensure your Ollama models are fully downloaded and optimized.

By systematically working through these solutions, you should be able to identify and conquer that frustrating 60-second timeout and get back to productive, uninterrupted AI interactions!

The Future: Streaming and Robustness

As we move further into the age of advanced AI, the expectation for resilient connections and seamless user experiences with large language models is only going to grow. The 60-second timeout issue, while frustrating, highlights a critical area for improvement within the ecosystem of tools like Ollama and Open WebUI. The ideal solution for long-running requests isn't just about cranking up a timeout value; it's about building inherently robust streaming capabilities that are designed to handle variable response times without relying on a single, fragile, long-lived connection that can be arbitrarily cut short by various network or proxy layers. We noted that even streaming mode has the same issue in the original bug report, which really underscores that the problem isn't the lack of streaming, but rather an external timeout interfering with the streaming mechanism itself. This means that while data might be chunked and sent, an intermediate proxy or application layer is still enforcing its own connection duration limit, effectively nullifying the benefits of streaming for truly long outputs. This kind of behavior impedes the very purpose of conversational AI, where users anticipate continuous, uninterrupted dialogue and output from their models. The developer community plays a huge role here. By diligently reporting these issues, providing detailed logs, and collaborating on potential fixes, we can collectively push for Open WebUI enhancements and Ollama streaming improvements that prioritize stability and user experience for even the most demanding models. Imagine a future where using a codellama:70b model for an hour-long coding session never results in a dropped connection – that's the goal! This requires not only robust software design within Open WebUI but also clear documentation and guidance on configuring proxy settings and Docker environments to prevent these common pitfalls. Ultimately, our aim is to ensure that the power of large language models is fully accessible and reliable, making frustrating connection timeouts a thing of the past and paving the way for truly productive and engaging AI interactions without arbitrary limits. Let's continue to advocate for and build systems that are as patient and persistent as the models they host.