Intermittent sandbox connection failure after Dify upgrade (1.10.1-fix.1 → 1.15.0)

[yanpx169]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.15.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I am deploying in an offline docker compose environment, when upgrading the version from dify 1.10.1-fix.1 to 1.15.0,
an error occurred, please guide me on how to resolve this?

Dify will appear in version 1.10, but the probability of its occurrence is very low, approximately 10%. The probability of Dify appearing in version 1.15 is around 50%

error info:

sandbox-1           | INFO:     192.168.64.11:35966 - "POST /v1/sandbox/run HTTP/1.1" 200 OK
worker-1            | 2026-07-06 07:44:55.989 INFO [GraphWorker-1] [_client.py:1025] 69edaaac7b335c3ba4ff38c3a86011c0 - HTTP Request: POST http://sandbox:8194/v1/sandbox/run "HTTP/1.1 200 OK"
worker-1            | 2026-07-06 07:44:56.129 ERROR [GraphDispatcher] [error_handler.py:104]  - Node 1782289548987 failed with ABORT strategy: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Server disconnected without sending a response. )
worker-1            | 2026-07-06 07:44:56.348 ERROR [Thread-129 (_generate_worker)] [workflow_entry.py:248] 69edaaac7b335c3ba4ff38c3a86011c0 - Unknown Error when workflow entry running
worker-1            | Traceback (most recent call last):
worker-1            |   File "/app/api/core/workflow/workflow_entry.py", line 244, in run
worker-1            |     yield from generator
worker-1            |   File "/app/api/core/workflow/workflow_entry.py", line 57, in iter_dify_graph_engine_events
worker-1            |     yield from filter_graph_events(
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/filters/chain.py", line 21, in filter_graph_events
worker-1            |     for event in events:
worker-1            |                  ^^^^^^
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 309, in run
worker-1            |     yield from lifecycle.run()
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 77, in run
worker-1            |     yield from self.emit_terminal_events()
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 341, in _emit_terminal_events
worker-1            |     raise error
worker-1            | RuntimeError: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Server disconnected without sending a response. )
worker-1            | 2026-07-06 07:44:56.354 ERROR [GraphDispatcher] [error_handler.py:104]  - Node 1778722729299 failed with ABORT strategy: Failed to invoke tool [网络组件]通知模板: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Server disconnected without sending a response. )
nginx-1             | 10.xx.1xx.1x1 - - [06/Jul/2026:07:44:56 +0000] "POST /console/api/apps/98d26167-9ac8-4f05-944e-0aea2d905224/advanced-chat/workflows/draft/run HTTP/1.1" 200 122575 "http://10.231.147.37/app/98d26167-9ac8-4f05-944e-0aea2d905224/workflow" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36" "-"
worker-1            | 2026-07-06 07:44:56.524 INFO [Dummy-118] [trace.py:128] 69edaaac7b335c3ba4ff38c3a86011c0 - Task tasks.app_generate.workflow_execute_task.workflow_based_app_execution_task[03c466e7-a725-4bd8-9695-349fe3521ea8] succeeded in 330.21767717879266s: None
worker-1            | 2026-07-06 07:44:58.527 ERROR [Thread-119 (_generate_worker)] [workflow_entry.py:248] 69edaaac7b335c3ba4ff38c3a86011c0 - Unknown Error when workflow entry running
worker-1            | Traceback (most recent call last):
worker-1            |   File "/app/api/core/workflow/workflow_entry.py", line 244, in run
worker-1            |     yield from generator
worker-1            |   File "/app/api/core/workflow/workflow_entry.py", line 57, in iter_dify_graph_engine_events
worker-1            |     yield from filter_graph_events(
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/filters/chain.py", line 21, in filter_graph_events
worker-1            |     for event in events:
worker-1            |                  ^^^^^^
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 309, in run
worker-1            |     yield from lifecycle.run()
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 77, in run
worker-1            |     yield from self.emit_terminal_events()
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 341, in _emit_terminal_events
worker-1            |     raise error
worker-1            | RuntimeError: Failed to invoke tool [网络组件]通知模板: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Server disconnected without sending a response. )
nginx-1             | 10.xx.1xx.1x1 - - [06/Jul/2026:07:44:59 +0000] "GET /console/api/apps/98d26167-9ac8-4f05-944e-0aea2d905224/workflows/draft/system-variables HTTP/1.1" 200 13 "http://10.231.147.37/app/98d26167-9ac8-4f05-944e-0aea2d905224/workflow" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36

✔️ Expected Behavior

Expectations should be running normally

❌ Actual Behavior

No response

[dosubot]

This is a confirmed issue tied to the dify-sandbox:0.2.15 image that ships with Dify 1.15.0. The sandbox has regressions including seccomp filter initialization failures and an incomplete syscall whitelist, which cause it to intermittently crash mid-response — explaining why you see HTTP 200 logged but then "Server disconnected without sending a response" [1] [2].

Recommended fix — downgrade the sandbox image to 0.2.14 in your docker-compose.yaml:

sandbox:
  image: langgenius/dify-sandbox:0.2.14  # was 0.2.15

Then restart the sandbox container. This should reduce the failure rate back to what you experienced on 1.10.x [1].

An upstream fix is being tracked in dify-sandbox#275 to address the root cause (seccomp whitelist gaps) [2]. Once that merges and a new sandbox image is released, you'll be able to upgrade again safely.

If you're also hitting this under heavy concurrency, you can tune the sandbox worker count in docker/volumes/sandbox/conf/config.yaml [3]:

max_workers: 8    # default is 4
max_requests: 100 # default is 50

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[yanpx169]

@dosu

self-hosted (Docker),
which is relatively safe in the offline environment of the internal network. Due to the many restrictions of the official sandbox image, the sandbox image I used before was svcvit/dify-sandbox-py:0.1.4. However, after replacing the langgenius/dify-sandbox:0.2.14 image, all the original code nodes have encountered problems to varying degrees and are almost completely paralyzed.

error:

/opt/python/lib/python3.14/site-packages/requests/__init__.py:113: RequestsDependencyWarning: urllib3 (2.6.3) or chardet (7.4.3)/charset_normalizer (3.4.6) doesn't match a supported version!
  warnings.warn(
error: operation not permitted

docker compose logs:

sandbox-1           | {"time":"2026-07-07T19:25:11.78980989+08:00","level":"ERROR","msg":"process finished with error","status":"signal: bad system call (core dumped)"}
sandbox-1           | [GIN] 2026/07/07 - 19:25:11 | 200 |  1.428527812s |   192.168.16.11 | POST     "/v1/sandbox/run"
worker-1            | 2026-07-07 11:25:11.793 INFO [GraphWorker-0] [_client.py:1025] dab0b0ea5bcc5dfabfcdf5db9cbb96bb - HTTP Request: POST http://sandbox:8194/v1/sandbox/run "HTTP/1.1 200 OK"
sandbox-1           | {"time":"2026-07-07T19:25:14.24480928+08:00","level":"ERROR","msg":"process finished with error","status":"signal: bad system call (core dumped)"}
sandbox-1           | [GIN] 2026/07/07 - 19:25:14 | 200 |  1.430031396s |   192.168.16.11 | POST     "/v1/sandbox/run"
worker-1            | 2026-07-07 11:25:14.248 INFO [GraphWorker-0] [_client.py:1025] dab0b0ea5bcc5dfabfcdf5db9cbb96bb - HTTP Request: POST http://sandbox:8194/v1/sandbox/run "HTTP/1.1 200 OK"
worker-1            | 2026-07-07 11:25:14.254 ERROR [GraphDispatcher] [error_handler.py:104]  - Node 1780900046148 failed with ABORT strategy: /opt/python/lib/python3.14/site-packages/requests/__init__.py:113: RequestsDependencyWarning: urllib3 (2.6.3) or chardet (7.4.3)/charset_normalizer (3.4.6) doesn't match a supported version!
worker-1            |   warnings.warn(
worker-1            | error: operation not permitted
worker-1            | 
worker-1            | 2026-07-07 11:25:14.357 ERROR [GraphDispatcher] [error_handler.py:104]  - Node 1780886716226 failed with ABORT strategy: /opt/python/lib/python3.14/site-packages/requests/__init__.py:113: RequestsDependencyWarning: urllib3 (2.6.3) or chardet (7.4.3)/charset_normalizer (3.4.6) doesn't match a supported version!
worker-1            |   warnings.warn(
worker-1            | error: operation not permitted
worker-1            | 
sandbox-1           | [GIN] 2026/07/07 - 19:25:14 | 200 |      84.583µs |             ::1 | GET      "/health"
worker-1            | 2026-07-07 11:25:14.461 INFO [Dummy-653] [trace.py:128] dab0b0ea5bcc5dfabfcdf5db9cbb96bb - Task tasks.app_generate.workflow_execute_task.workflow_based_app_execution_task[72deb247-3398-410e-8bea-dc2d92269c5d] succeeded in 4.191267302259803s: None
worker-1            | 2026-07-07 11:25:14.471 ERROR [Thread-654 (_generate_worker)] [workflow_entry.py:248] dab0b0ea5bcc5dfabfcdf5db9cbb96bb - Unknown Error when workflow entry running
worker-1            | Traceback (most recent call last):
worker-1            |   File "/app/api/core/workflow/workflow_entry.py", line 244, in run
worker-1            |     yield from generator
worker-1            |   File "/app/api/core/workflow/workflow_entry.py", line 57, in iter_dify_graph_engine_events
worker-1            |     yield from filter_graph_events(
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/filters/chain.py", line 21, in filter_graph_events
worker-1            |     for event in events:
worker-1            |                  ^^^^^^
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 309, in run
worker-1            |     yield from lifecycle.run()
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 77, in run
worker-1            |     yield from self.emit_terminal_events()
worker-1            |   File "/app/api/.venv/lib/python3.12/site-packages/graphon/graph_engine/graph_engine.py", line 341, in _emit_terminal_events
worker-1            |     raise error
worker-1            | RuntimeError: /opt/python/lib/python3.14/site-packages/requests/__init__.py:113: RequestsDependencyWarning: urllib3 (2.6.3) or chardet (7.4.3)/charset_normalizer (3.4.6) doesn't match a supported version!
worker-1            |   warnings.warn(
worker-1            | error: operation not permitted
worker-1            | 
worker-1            | 

The current configuration is as follows:

volumes/sandbox/conf/config.yaml

app:
  port: 8194
  debug: True
  key: dify-sandbox
max_workers: 8
max_requests: 100
worker_timeout: 300
#python_path: /usr/local/bin/python3
python_path: /opt/python/bin/python3
nodejs_path: /usr/local/bin/node
enable_network: True # please make sure there is no network risk in your environment
#allowed_syscalls: # please leave it empty if you have no idea how seccomp works
allowed_syscalls: [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,72,78,79,80,89,95,96,97,98,99,102,104,105,106,107,108,110,131,137,138,157,158,186,202,217,218,228,231,232,233,234,257,258,262,270,271,273,274,281,282,283,284,288,290,291,293,302,307,318,332,334]
proxy:
  socks5: ''
  http: ''
  https: ''

allowed_hosts:
  - "127.0.0.1"
  - "127.0.0.11"   
  - "172.30.0.12"  
  - "docker-api-1"

docker-compose.yaml :

  # The DifySandbox
  sandbox:
    #image: swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/svcvit/dify-sandbox-py:0.1.4
    image: langgenius/dify-sandbox:0.2.14
    restart: always
    env_file:
      - path: ./envs/core-services/sandbox.env
        required: false
      - path: ./envs/security.env
        required: false
      - ./.env
    #放宽 seccomp
    privileged: true
    security_opt:
      - seccomp:unconfined
    environment:
      # The DifySandbox configurations
      # Make sure you are changing this key for your deployment with a strong key.
      # You can generate a strong key using `openssl rand -base64 42`.
      API_KEY: ${SANDBOX_API_KEY:-dify-sandbox}
      GIN_MODE: ${SANDBOX_GIN_MODE:-release}
      WORKER_TIMEOUT: ${SANDBOX_WORKER_TIMEOUT:-15}
      ENABLE_NETWORK: ${SANDBOX_ENABLE_NETWORK:-true}
      #HTTP_PROXY: ${SANDBOX_HTTP_PROXY:-http://ssrf_proxy:3128}
      #HTTPS_PROXY: ${SANDBOX_HTTPS_PROXY:-http://ssrf_proxy:3128}
      SANDBOX_PORT: ${SANDBOX_PORT:-8194}
      PIP_MIRROR_URL: https://artsz.zte.com.cn/artifactory/api/pypi/public-pypi-virtual/simple
      PIP_TRUSTED_HOST: artsz.zte.com.cn
      TZ: Asia/Shanghai
    volumes:
      - /home/dify/volumes/sandbox/dependencies:/dependencies
      - /home/dify/volumes/sandbox/conf:/conf
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8194/health"]
    networks:
      - ssrf_proxy_network
      - default

my code:

import requests
from io import BytesIO
import zipfile
import xml.etree.ElementTree as ET
import warnings

warnings.filterwarnings('ignore')

base_url = 'http://docker-api-1:5001'

# 辅助函数：判断特征词是否被包含在列表的某个列名中
def contains_keyword(columns, keyword):
    return any(keyword in str(col) for col in columns)


def fast_read_excel_headers(file_bytes):
    """
    终极极速读取方案：纯底层XML解析
    完美支持 inlineStr(畸形网管文件) 和 共享字符串表(正常Excel文件)，毫秒级响应
    """
    strategy = "未知"
    ...

    except Exception as e:
        return [], f" {str(e)}"

    return [], ""


def main(url, name) -> dict:
    # 1、拼接文件下载地址
    full_url = base_url + url

    # 2、通过request方法获取文件内容
    try:
        response = requests.get(full_url, timeout=30)
    except Exception as e:
        return {"status": "error", "result": {}, "message": f"请求异常: {str(e)}"}

    # 3. 检查响应状态
    if response.status_code != 200:
        return {
            "status": "error",
            "result": {},
            "message": f"请求失败，状态码: {response.status_code}"
        }
    
    ...

    # 6. 返回识别结果，将当前策略放入 message 中
    return {
        "status": "success",
        "result": {
            "data_type": file_type,
            "file_name": name,
            # "detected_columns": columns
        },
        "message": f"解析策略: {strategy}"
    }

The above code runs normally in the original dify1.10.1-fix.1 version using svcvit/dify-sandbox-py:0.1.4 for sandbox.

Request for help on how to solve this problem.
The goal is to ensure that the original functional process can run normally after updating to dify1.15.

[dosubot]

The core issue is that the sandbox applies its own internal seccomp filter to user code, completely independent of Docker-level settings. So privileged: true and security_opt: seccomp:unconfined only affect the sandbox container process — they do not disable the seccomp filter applied to the Python code running inside the sandbox [1]. That's why you still see "operation not permitted" / "bad system call (core dumped)".

Additionally, allowed_syscalls in config.yaml uses REPLACE semantics, not APPEND [1]. When you set your custom syscall list, it becomes the entire whitelist. If any syscall your code needs is missing from that list, it will be blocked. Your list covers many common syscalls but may still be missing some that Python 3.14 + modern glibc require.

Here's what to try:

1. Add missing syscalls to your list

Python 3.14 (which the sandbox uses internally at /opt/python/bin/python3) likely needs additional syscalls beyond what you've listed. Key ones to add [1]:

Number	Syscall	Purpose
17	pread64	File I/O
19	readv	Vectored I/O
20	writev	Vectored I/O
213	epoll_create	Event polling
232	epoll_wait	Event polling
233	epoll_ctl	Event polling
435	clone3	Process creation (glibc 2.34+)
334	rseq	Restartable sequences

Try expanding your allowed_syscalls to include these. Since you're in a trusted offline network, you could use a very permissive list (syscalls 0-450+) to unblock yourself, then narrow it down later.

2. Alternative: leave allowed_syscalls empty

If you remove/comment out the allowed_syscalls line entirely, the sandbox will use its default built-in whitelist (which may or may not be sufficient for Python 3.14 on 0.2.14):

#allowed_syscalls:

3. Consider going back to your previous image temporarily

Since svcvit/dify-sandbox-py:0.1.4 worked for you on 1.10.x and your environment is trusted/offline, you could continue using it with 1.15.0 as long as the sandbox API contract hasn't changed. The sandbox HTTP interface (POST /v1/sandbox/run) is fairly stable between versions.

4. Watch for the upstream fix

PR langgenius/dify-sandbox#275 is in progress to fix both the REPLACE→APPEND semantics and add the missing modern syscalls to the default whitelist [1]. Once merged, a new sandbox image should resolve this properly.

Quick diagnostic: Try setting a very broad syscall list (e.g., all numbers 0–450) in your config.yaml and restart the sandbox. If the errors go away, you know it's purely a missing syscall issue and can then narrow down the exact ones needed.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[yanpx169]

@dosu

Modify the volumes/sandbox/conf/config. The operation not permitted problem has been solved, modify the content is as follows:

app:
  port: 8194
  debug: True
  key: dify-sandbox
max_workers: 8
max_requests: 100
worker_timeout: 300
#python_path: /usr/local/bin/python3
python_path: /opt/python/bin/python3
nodejs_path: /usr/local/bin/node
enable_network: True # please make sure there is no network risk in your environment
#allowed_syscalls: # please leave it empty if you have no idea how seccomp works
# 权限全开：0-450 全部系统调用号，覆盖 x86_64 所有标准及现代系统调用
allowed_syscalls: [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450]
proxy:
  socks5: ''
  http: ''
  https: ''

However, a new problem has emerged. It was found that the code that could normally obtain the files uploaded by users can no longer do so properly. I need to process and judge the files uploaded by users in the code node and return the results. After replacing langgenius/dify-sandbox:0.2.14, how should this problem be solved?

请求异常: HTTPConnectionPool(host='docker-api-1', port=5001): Max retries exceeded with url: /files/895b46d8-cd0c-455e-a087-abd839c97a2e/file-preview?timestamp=1783438136&nonce=00ae06a65240917a02c8e090e837b710&sign=gZSGAOmMOVC60IbnolIQpeiErxiAlLmwXZ2WFMkhr7s%3D (Caused by NameResolutionError(\"HTTPConnection(host='docker-api-1', port=5001): Failed to resolve 'docker-api-1' ([Errno -3] Temporary failure in name resolution)\"))

my code:

import requests
from io import BytesIO
import zipfile
import xml.etree.ElementTree as ET
import warnings

warnings.filterwarnings('ignore')

base_url = 'http://docker-api-1:5001'

# 辅助函数：判断特征词是否被包含在列表的某个列名中
def contains_keyword(columns, keyword):
    return any(keyword in str(col) for col in columns)


def fast_read_excel_headers(file_bytes):
    """
    终极极速读取方案：纯底层XML解析
    完美支持 inlineStr(畸形网管文件) 和 共享字符串表(正常Excel文件)，毫秒级响应
    """
    strategy = "未知"
    ...

    except Exception as e:
        return [], f" {str(e)}"

    return [], ""


def main(url, name) -> dict:
    # 1、拼接文件下载地址
    full_url = base_url + url

    # 2、通过request方法获取文件内容
    try:
        response = requests.get(full_url, timeout=30)
    except Exception as e:
        return {"status": "error", "result": {}, "message": f"请求异常: {str(e)}"}

    # 3. 检查响应状态
    if response.status_code != 200:
        return {
            "status": "error",
            "result": {},
            "message": f"请求失败，状态码: {response.status_code}"
        }
    
    ...

    # 6. 返回识别结果，将当前策略放入 message 中
    return {
        "status": "success",
        "result": {
            "data_type": file_type,
            "file_name": name,
            # "detected_columns": columns
        },
        "message": f"解析策略: {strategy}"
    }

[dosubot]

Glad the "operation not permitted" issue is resolved! 🎉

The new DNS resolution failure has two likely causes:

1. The sandbox routes all traffic through the SSRF proxy

The official langgenius/dify-sandbox:0.2.14 image proxies all HTTP/HTTPS requests through ssrf_proxy:3128 [1]. In Dify 1.15.0, this proxy uses a deny-by-default policy that blocks access to private/internal addresses unless explicitly allowed.

Since you've commented out the proxy settings in your docker-compose.yaml but the sandbox image may still use them internally, and you've also set enable_network: True with empty proxy in config.yaml — the issue is likely that docker-api-1 isn't resolvable from the sandbox's network.

2. Docker DNS only resolves service names, not container names

Docker Compose's built-in DNS resolves service names (e.g., api) — not container names (e.g., docker-api-1). Since the sandbox is on ssrf_proxy_network, it can only resolve other services on that same network by their service name [2].

Solutions (try in order):

Option A — If docker-api-1 is your Dify API service, use the service name instead:

base_url = 'http://api:5001'

Option B — If docker-api-1 is a separate container, add it to the ssrf_proxy_network in your docker-compose and reference it by its service name.

Option C — Allow private domains through the SSRF proxy by adding to your .env:

SSRF_PROXY_ALLOW_PRIVATE_DOMAINS=docker-api-1,api
SSRF_PROXY_ALLOW_PRIVATE_IPS=172.0.0.0/8,192.168.0.0/16

Option D — Add extra_hosts to your sandbox service in docker-compose to hardcode the resolution:

sandbox:
  extra_hosts:
    - "docker-api-1:172.x.x.x"  # Replace with the actual IP of your API container

Your old svcvit/dify-sandbox-py:0.1.4 image likely didn't enforce SSRF proxy routing or had different network isolation, which is why this worked before. The official sandbox image is more restrictive by design.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[yanpx169]

Option A is very effective. Thank you for your guidance。