langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-22 12:36:14 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

'Connection Error' when setup OpenAI on Model Provider after upgrading to 0.14.1 #7290

New Issue
Closed
opened 2026-02-21 18:19:50 -05:00 by yindo · 18 comments
yindo commented 2026-02-21 18:19:50 -05:00
Owner
Copy Link
Copy Source

Originally created by @Ynewtime on GitHub (Dec 19, 2024).

Self Checks

  • 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 (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.14.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Same network configuration (Chinese Mainland with Clash Proxy), same environment (WSL2 + Docker Desktop), one was launched from 0.13.2 and the other launched from 0.14.1:

image

image

Notice that the app launched from 0.13.2 can setup OpenAI (and chat) successfully, but the app launched from 0.14.1 cannot even setup OpenAI with error: 'Connection Error' as shared screenshots.

Environment: WSL2 2.3.26.0 + Docker Desktop v4.37.1
Network: China Mainland with Clash Proxy
Reproduction:

  1. for 0.13.2:
git clone https://github.com/langgenius/dify.git dify-0132  # clone the latest repo
git checkout 0ff8bd2  # switch to 0.13.2
cd docker
cp .env.example .env
docker compose -p dify-0132 up -d
  1. for 0.14.1
git clone https://github.com/langgenius/dify.git dify-0141  # clone the latest repo
cd docker
cp .env.example .env
# modify the EXPOSE_NGINX_PORT and EXPOSE_NGINX_SSL_PORT env to 3000 and 3001
docker compose -p dify-0141 up -d

...both apps can start up normally as per the reproduction steps above with no other configurations differed. Only the error happens in OpenAI setup of 0.14.1.

✔️ Expected Behavior

0.14.1 seems to have proxy configuration enhanced, as per this https://github.com/langgenius/dify/pull/11681, though it did introduces connection error.

Expect the app to behave as the same as 0.13.2 version.

❌ Actual Behavior

0.14.1: OpenAI and Claude API cannot be setup succesfully, connection error.

image

Originally created by @Ynewtime on GitHub (Dec 19, 2024). ### Self Checks - [X] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [X] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [X] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [X] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.14.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Same network configuration (Chinese Mainland with Clash Proxy), same environment (WSL2 + Docker Desktop), one was launched from 0.13.2 and the other launched from 0.14.1: ![image](https://github.com/user-attachments/assets/109eccec-db1b-4369-bc52-72f55ad2c411) ![image](https://github.com/user-attachments/assets/fabbe830-12df-40a7-8856-b720ca9bb685) Notice that the app launched from 0.13.2 can setup OpenAI (and chat) successfully, but the app launched from 0.14.1 cannot even setup OpenAI with error: 'Connection Error' as shared screenshots. Environment: WSL2 2.3.26.0 + Docker Desktop v4.37.1 Network: China Mainland with Clash Proxy Reproduction: 1. for 0.13.2: ```sh git clone https://github.com/langgenius/dify.git dify-0132 # clone the latest repo git checkout 0ff8bd2 # switch to 0.13.2 cd docker cp .env.example .env docker compose -p dify-0132 up -d ``` 2. for 0.14.1 ```sh git clone https://github.com/langgenius/dify.git dify-0141 # clone the latest repo cd docker cp .env.example .env # modify the EXPOSE_NGINX_PORT and EXPOSE_NGINX_SSL_PORT env to 3000 and 3001 docker compose -p dify-0141 up -d ``` ...both apps can start up normally as per the reproduction steps above with no other configurations differed. Only the error happens in OpenAI setup of 0.14.1. ### ✔️ Expected Behavior 0.14.1 seems to have proxy configuration enhanced, as per this https://github.com/langgenius/dify/pull/11681, though it did introduces connection error. Expect the app to behave as the same as 0.13.2 version. ### ❌ Actual Behavior 0.14.1: OpenAI and Claude API cannot be setup succesfully, connection error. ![image](https://github.com/user-attachments/assets/39eeb73d-5248-4e7e-a760-55715b02d4ac)
yindo added the 🐞 bug label 2026-02-21 18:19:50 -05:00
yindo closed this issue 2026-02-21 18:19:50 -05:00
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 19, 2024):

Hey @Ynewtime! 👋 I'm here to help you with your Dify issue. I can assist with bug solving, answering questions, and guide you on becoming a contributor. Let's dive into resolving the issue together!

The 'Connection Error' you're experiencing when setting up OpenAI on the Model Provider after upgrading to version 0.14.1 is likely due to changes in how Docker Compose handles proxy settings in this version. In Dify 0.14.0 and likely 0.14.1, Docker Compose reads the system proxy environment variables (HTTP_PROXY and HTTPS_PROXY), which can interfere with API connections if these variables are set to values like 127.0.0.1:7890.

To resolve this issue, you can try the following:

  1. Unset the system proxy environment variables (HTTP_PROXY and HTTPS_PROXY) on the Dify host machine before running Docker Compose.

  2. Comment out the proxy-related lines added in commit #11681 in the Docker Compose configuration if the proxy settings are not needed.

These steps should help establish the connection successfully, similar to how it worked in version 0.13.2 [1].

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other

@dosubot[bot] commented on GitHub (Dec 19, 2024): <!-- Greeting --> Hey @Ynewtime! 👋 I'm here to help you with your Dify issue. I can assist with bug solving, answering questions, and guide you on becoming a contributor. Let's dive into resolving the issue together! <!-- Answer --> The 'Connection Error' you're experiencing when setting up OpenAI on the Model Provider after upgrading to version 0.14.1 is likely due to changes in how Docker Compose handles proxy settings in this version. In Dify 0.14.0 and likely 0.14.1, Docker Compose reads the system proxy environment variables (HTTP_PROXY and HTTPS_PROXY), which can interfere with API connections if these variables are set to values like 127.0.0.1:7890. To resolve this issue, you can try the following: 1. Unset the system proxy environment variables (HTTP_PROXY and HTTPS_PROXY) on the Dify host machine before running Docker Compose. 2. Comment out the proxy-related lines added in commit #11681 in the Docker Compose configuration if the proxy settings are not needed. These steps should help establish the connection successfully, similar to how it worked in version 0.13.2 <sup>[[1]](https://github.com/langgenius/dify/issues/11739)</sup>. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/26268820-04ca-413b-8ba6-df5a46eafe9e?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/26268820-04ca-413b-8ba6-df5a46eafe9e?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/26268820-04ca-413b-8ba6-df5a46eafe9e?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/26268820-04ca-413b-8ba6-df5a46eafe9e?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/26268820-04ca-413b-8ba6-df5a46eafe9e?feedback_type=hallucination) | [Other](https://app.dosu.dev/response-feedback/26268820-04ca-413b-8ba6-df5a46eafe9e?feedback_type=other)</sup>
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@Ynewtime commented on GitHub (Dec 19, 2024):

To resolve this issue, you can try the following:

  1. Unset the system proxy environment variables (HTTP_PROXY and HTTPS_PROXY) on the Dify host machine before running Docker Compose.
  2. Comment out the proxy-related lines added in commit fix: fix proxy for docker #11681 in the Docker Compose configuration if the proxy settings are not needed.

These steps should help establish the connection successfully, similar to how it worked in version 0.13.2 [1].

I've tried both these suggestions but none of them work in 0.14.1, same issue.

@Ynewtime commented on GitHub (Dec 19, 2024): > To resolve this issue, you can try the following: > > 1. Unset the system proxy environment variables (HTTP_PROXY and HTTPS_PROXY) on the Dify host machine before running Docker Compose. > 2. Comment out the proxy-related lines added in commit [fix: fix proxy for docker #11681](https://github.com/langgenius/dify/pull/11681) in the Docker Compose configuration if the proxy settings are not needed. > > These steps should help establish the connection successfully, similar to how it worked in version 0.13.2 [[1]](https://github.com/langgenius/dify/issues/11739). I've tried both these suggestions but none of them work in 0.14.1, same issue.
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Dec 19, 2024):

https://github.com/langgenius/dify/pull/11681

I don't think it's related. Because these 2 settings have exist for a while.

@crazywoola commented on GitHub (Dec 19, 2024): https://github.com/langgenius/dify/pull/11681 I don't think it's related. Because these 2 settings have exist for a while.
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@Ynewtime commented on GitHub (Dec 19, 2024):

#11681

I don't think it's related. Because these 2 settings have exist for a while.

Not sure if it's related but as per the .env.example file comparison between 0.13.2 and 0.14.1, the HTTP(S)_PROXY config exist in 0.14.1 only?

图片

@Ynewtime commented on GitHub (Dec 19, 2024): > #11681 > > I don't think it's related. Because these 2 settings have exist for a while. Not sure if it's related but as per the [.env.example file comparison between 0.13.2 and 0.14.1](https://github.com/langgenius/dify/compare/0.13.2...0.14.1?diff=split&w=#diff-ec10582dde9af6c0c622084d3244b29d496260613491c430ec8958565e2f31b4R924), the HTTP(S)_PROXY config exist in 0.14.1 only? ![图片](https://github.com/user-attachments/assets/b60c0784-b2ec-426f-895b-c0fce86f26e0)
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 19, 2024):

@Ynewtime Hi, I am the one giving those 2 suggestions in #11739. If you comment out those 2 lines and then docker compose, the HTTP(S)_PROXY should no longer affect the container. You can look at the dify api container log for more detailed error tracing.

@AugNSo commented on GitHub (Dec 19, 2024): @Ynewtime Hi, I am the one giving those 2 suggestions in #11739. If you comment out those 2 lines and then docker compose, the HTTP(S)_PROXY should no longer affect the container. You can look at the dify api container log for more detailed error tracing.
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@Ynewtime commented on GitHub (Dec 19, 2024):

@Ynewtime Hi, I am the one giving those 2 suggestions in #11739. If you comment out those 2 lines and then docker compose, the HTTP(S)_PROXY should no longer affect the container. You can look at the dify api container log for more detailed error tracing.

Hi there, thanks. I'ved tried (yesterday and today with the latest commit) commented out those 2 lines but same issue there. Kindly find the dify-api container full logs here:

2024-12-20 11:25:36 None of PyTorch, TensorFlow >= 2.0, or Flax have been found. Models won't be available and only tokenizers, configuration and file/data utilities can be used.
2024-12-20 11:25:30 Running migrations
2024-12-20 11:25:43 2024-12-20 03:25:43,435.435 INFO [MainThread] [utils.py:148] - Note: NumExpr detected 16 cores but "NUMEXPR_MAX_THREADS" not set, so enforcing safe limit of 8.
2024-12-20 11:25:43 2024-12-20 03:25:43,435.435 INFO [MainThread] [utils.py:160] - NumExpr defaulting to 8 threads.
2024-12-20 11:25:47 /app/api/.venv/lib/python3.12/site-packages/tencentcloud/hunyuan/v20230901/models.py:6034: SyntaxWarning: invalid escape sequence '\_'
2024-12-20 11:25:47   """function名称，只能包含a-z，A-Z，0-9，\_或-
2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/__init__.py:44: SyntaxWarning: invalid escape sequence '\.'
2024-12-20 11:25:49   re_han_default = re.compile("([\u4E00-\u9FD5a-zA-Z0-9+#&\._%\-]+)", re.U)
2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/__init__.py:46: SyntaxWarning: invalid escape sequence '\s'
2024-12-20 11:25:49   re_skip_default = re.compile("(\r\n|\s)", re.U)
2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/finalseg/__init__.py:78: SyntaxWarning: invalid escape sequence '\.'
2024-12-20 11:25:49   re_skip = re.compile("([a-zA-Z0-9]+(?:\.\d+)?%?)")
2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/posseg/__init__.py:16: SyntaxWarning: invalid escape sequence '\.'
2024-12-20 11:25:49   re_skip_detail = re.compile("([\.0-9]+|[a-zA-Z0-9]+)")
2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/posseg/__init__.py:17: SyntaxWarning: invalid escape sequence '\.'
2024-12-20 11:25:49   re_han_internal = re.compile("([\u4E00-\u9FD5a-zA-Z0-9+#&\._]+)")
2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/posseg/__init__.py:18: SyntaxWarning: invalid escape sequence '\s'
2024-12-20 11:25:49   re_skip_internal = re.compile("(\r\n|\s)")
2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/posseg/__init__.py:21: SyntaxWarning: invalid escape sequence '\.'
2024-12-20 11:25:49   re_num = re.compile("[\.0-9]+")
2024-12-20 11:25:58 Preparing database migration...
2024-12-20 11:25:59 2024-12-20 03:25:59,232.232 INFO [pre_load_builtin_providers_cache] [font_manager.py:1578] - generated new fontManager
2024-12-20 11:26:04 Database migration skipped
2024-12-20 11:26:07 [2024-12-20 03:26:07 +0000] [1] [INFO] Starting gunicorn 23.0.0
2024-12-20 11:26:07 [2024-12-20 03:26:07 +0000] [1] [INFO] Listening at: http://0.0.0.0:5001 (1)
2024-12-20 11:26:07 [2024-12-20 03:26:07 +0000] [1] [INFO] Using worker: gevent
2024-12-20 11:26:07 [2024-12-20 03:26:07 +0000] [52] [INFO] Booting worker with pid: 52
2024-12-20 11:26:09 None of PyTorch, TensorFlow >= 2.0, or Flax have been found. Models won't be available and only tokenizers, configuration and file/data utilities can be used.
2024-12-20 11:26:12 2024-12-20 03:26:12,027.027 INFO [MainThread] [utils.py:148] - Note: NumExpr detected 16 cores but "NUMEXPR_MAX_THREADS" not set, so enforcing safe limit of 8.
2024-12-20 11:26:12 2024-12-20 03:26:12,027.027 INFO [MainThread] [utils.py:160] - NumExpr defaulting to 8 threads.
2024-12-20 11:26:27 2024-12-20 03:26:27,092.092 WARNING [Dummy-1] [version.py:37] - Check update version error: HTTPSConnectionPool(host='updates.dify.ai', port=443): Max retries exceeded with url: /?current_version=0.14.1 (Caused by ProxyError('Unable to connect to proxy', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f64e2e2d9d0>: Failed to establish a new connection: [Errno 111] Connection refused'))).
2024-12-20 11:27:13 2024-12-20 03:27:13,899.899 INFO [Dummy-2] [_base_client.py:1086] - Retrying request to /chat/completions in 0.470940 seconds

My WSL2 configuration (.wslconfig):

# https://learn.microsoft.com/en-us/windows/wsl/wsl-config#main-wsl-settings
[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true

# https://learn.microsoft.com/en-us/windows/wsl/wsl-config#experimental-settings
[experimental]
autoMemoryReclaim=dropcache
sparseVhd=true
bestEffortDnsParsing=true
hostAddressLoopback=true

...notice that I've enabled the networkingMode=mirrored mode, which ensures the best network experience when developing in WSL2. With clash proxy enabled on Windows, you can use the clash proxy with no extra steps right in WSL2:

➜  docker git:(main) echo $http_proxy 
http://127.0.0.1:7890

But still, as I've mentioned, all the environment and configurations are the same for 0.13.2 and 0.14.1, but connection fails for 0.14.1 when configuring new Model Providers.

@Ynewtime commented on GitHub (Dec 19, 2024): > @Ynewtime Hi, I am the one giving those 2 suggestions in #11739. If you comment out those 2 lines and then docker compose, the HTTP(S)_PROXY should no longer affect the container. You can look at the dify api container log for more detailed error tracing. Hi there, thanks. I'ved tried (yesterday and today with the latest commit) commented out those 2 lines but same issue there. Kindly find the dify-api container full logs here: ```log 2024-12-20 11:25:36 None of PyTorch, TensorFlow >= 2.0, or Flax have been found. Models won't be available and only tokenizers, configuration and file/data utilities can be used. 2024-12-20 11:25:30 Running migrations 2024-12-20 11:25:43 2024-12-20 03:25:43,435.435 INFO [MainThread] [utils.py:148] - Note: NumExpr detected 16 cores but "NUMEXPR_MAX_THREADS" not set, so enforcing safe limit of 8. 2024-12-20 11:25:43 2024-12-20 03:25:43,435.435 INFO [MainThread] [utils.py:160] - NumExpr defaulting to 8 threads. 2024-12-20 11:25:47 /app/api/.venv/lib/python3.12/site-packages/tencentcloud/hunyuan/v20230901/models.py:6034: SyntaxWarning: invalid escape sequence '\_' 2024-12-20 11:25:47 """function名称，只能包含a-z，A-Z，0-9，\_或- 2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/__init__.py:44: SyntaxWarning: invalid escape sequence '\.' 2024-12-20 11:25:49 re_han_default = re.compile("([\u4E00-\u9FD5a-zA-Z0-9+#&\._%\-]+)", re.U) 2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/__init__.py:46: SyntaxWarning: invalid escape sequence '\s' 2024-12-20 11:25:49 re_skip_default = re.compile("(\r\n|\s)", re.U) 2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/finalseg/__init__.py:78: SyntaxWarning: invalid escape sequence '\.' 2024-12-20 11:25:49 re_skip = re.compile("([a-zA-Z0-9]+(?:\.\d+)?%?)") 2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/posseg/__init__.py:16: SyntaxWarning: invalid escape sequence '\.' 2024-12-20 11:25:49 re_skip_detail = re.compile("([\.0-9]+|[a-zA-Z0-9]+)") 2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/posseg/__init__.py:17: SyntaxWarning: invalid escape sequence '\.' 2024-12-20 11:25:49 re_han_internal = re.compile("([\u4E00-\u9FD5a-zA-Z0-9+#&\._]+)") 2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/posseg/__init__.py:18: SyntaxWarning: invalid escape sequence '\s' 2024-12-20 11:25:49 re_skip_internal = re.compile("(\r\n|\s)") 2024-12-20 11:25:49 /app/api/.venv/lib/python3.12/site-packages/jieba/posseg/__init__.py:21: SyntaxWarning: invalid escape sequence '\.' 2024-12-20 11:25:49 re_num = re.compile("[\.0-9]+") 2024-12-20 11:25:58 Preparing database migration... 2024-12-20 11:25:59 2024-12-20 03:25:59,232.232 INFO [pre_load_builtin_providers_cache] [font_manager.py:1578] - generated new fontManager 2024-12-20 11:26:04 Database migration skipped 2024-12-20 11:26:07 [2024-12-20 03:26:07 +0000] [1] [INFO] Starting gunicorn 23.0.0 2024-12-20 11:26:07 [2024-12-20 03:26:07 +0000] [1] [INFO] Listening at: http://0.0.0.0:5001 (1) 2024-12-20 11:26:07 [2024-12-20 03:26:07 +0000] [1] [INFO] Using worker: gevent 2024-12-20 11:26:07 [2024-12-20 03:26:07 +0000] [52] [INFO] Booting worker with pid: 52 2024-12-20 11:26:09 None of PyTorch, TensorFlow >= 2.0, or Flax have been found. Models won't be available and only tokenizers, configuration and file/data utilities can be used. 2024-12-20 11:26:12 2024-12-20 03:26:12,027.027 INFO [MainThread] [utils.py:148] - Note: NumExpr detected 16 cores but "NUMEXPR_MAX_THREADS" not set, so enforcing safe limit of 8. 2024-12-20 11:26:12 2024-12-20 03:26:12,027.027 INFO [MainThread] [utils.py:160] - NumExpr defaulting to 8 threads. 2024-12-20 11:26:27 2024-12-20 03:26:27,092.092 WARNING [Dummy-1] [version.py:37] - Check update version error: HTTPSConnectionPool(host='updates.dify.ai', port=443): Max retries exceeded with url: /?current_version=0.14.1 (Caused by ProxyError('Unable to connect to proxy', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f64e2e2d9d0>: Failed to establish a new connection: [Errno 111] Connection refused'))). 2024-12-20 11:27:13 2024-12-20 03:27:13,899.899 INFO [Dummy-2] [_base_client.py:1086] - Retrying request to /chat/completions in 0.470940 seconds ``` My WSL2 configuration (.wslconfig): ```powershell # https://learn.microsoft.com/en-us/windows/wsl/wsl-config#main-wsl-settings [wsl2] networkingMode=mirrored dnsTunneling=true autoProxy=true # https://learn.microsoft.com/en-us/windows/wsl/wsl-config#experimental-settings [experimental] autoMemoryReclaim=dropcache sparseVhd=true bestEffortDnsParsing=true hostAddressLoopback=true ``` ...notice that I've enabled the networkingMode=mirrored mode, which ensures the best network experience when developing in WSL2. With clash proxy enabled on Windows, you can use the clash proxy with no extra steps right in WSL2: ```sh ➜ docker git:(main) echo $http_proxy http://127.0.0.1:7890 ``` But still, as I've mentioned, all the environment and configurations are the same for 0.13.2 and 0.14.1, but connection fails for 0.14.1 when configuring new Model Providers.
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 20, 2024):

The log shows that your dify is still using the proxy setting.
2024-12-20 11:26:27 2024-12-20 03:26:27,092.092 WARNING [Dummy-1] [version.py:37] - Check update version error: HTTPSConnectionPool(host='updates.dify.ai', port=443): Max retries exceeded with url: /?current_version=0.14.1 (Caused by ProxyError('Unable to connect to proxy', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f64e2e2d9d0>: Failed to establish a new connection: [Errno 111] Connection refused'))).

Make sure you unset the HTTP_PROXY and HTTPS_PROXY, all upper case.
You can also try the following:

  • Stop clash as system proxy and use clash's TUN mode instead.
@AugNSo commented on GitHub (Dec 20, 2024): The log shows that your dify is still using the proxy setting. `2024-12-20 11:26:27 2024-12-20 03:26:27,092.092 WARNING [Dummy-1] [version.py:37] - Check update version error: HTTPSConnectionPool(host='updates.dify.ai', port=443): Max retries exceeded with url: /?current_version=0.14.1 (Caused by ProxyError('Unable to connect to proxy', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f64e2e2d9d0>: Failed to establish a new connection: [Errno 111] Connection refused'))).` Make sure you unset the HTTP_PROXY and HTTPS_PROXY, all upper case. You can also try the following: * Stop clash as system proxy and use clash's TUN mode instead.
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@yihong0618 commented on GitHub (Dec 20, 2024):

do we need to consider remove the http_proxy and https_proxy in env args...it will break some users

@yihong0618 commented on GitHub (Dec 20, 2024): do we need to consider remove the http_proxy and https_proxy in env args...it will break some users
yindo commented 2026-02-21 18:19:50 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 20, 2024):

#11681

I don't think it's related. Because these 2 settings have exist for a while.

@crazywoola This commit is added just 4 days ago, and is about the same time as Dify v0.14.0 rolled out when people start to upgrade and report issue.

By my understanding, this commit is trying to use proxy to pull docker image which I am sure there are other methods achieving the same. But not to digress from the discussion, the environment variables is passed to the dify api container as well. In the case of a proxy like 127.0.0.1:7890, dify will access its internal network address rather than the host machine, which caused problems.
image

@AugNSo commented on GitHub (Dec 20, 2024): > #11681 > > I don't think it's related. Because these 2 settings have exist for a while. @crazywoola This commit is added just 4 days ago, and is about the same time as Dify v0.14.0 rolled out when people start to upgrade and report issue. By my understanding, this commit is trying to use proxy to pull docker image which I am sure there are other methods achieving the same. But not to digress from the discussion, the environment variables is passed to the dify api container as well. In the case of a proxy like 127.0.0.1:7890, dify will access its internal network address rather than the host machine, which caused problems. ![image](https://github.com/user-attachments/assets/04116c23-4477-4765-8ce3-dfbc6b77de2a)
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@Ynewtime commented on GitHub (Dec 20, 2024):

The log shows that your dify is still using the proxy setting. 2024-12-20 11:26:27 2024-12-20 03:26:27,092.092 WARNING [Dummy-1] [version.py:37] - Check update version error: HTTPSConnectionPool(host='updates.dify.ai', port=443): Max retries exceeded with url: /?current_version=0.14.1 (Caused by ProxyError('Unable to connect to proxy', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f64e2e2d9d0>: Failed to establish a new connection: [Errno 111] Connection refused'))).

Make sure you unset the HTTP_PROXY and HTTPS_PROXY, all upper case. You can also try the following:

* Stop clash as system proxy and use clash's TUN mode instead.

"Make sure you unset the HTTP_PROXY and HTTPS_PROXY, all upper case" ---- this make no sense:

  1. I've tried unsetting the HTTP(S)_PROXY for 0.14.1, unfortunately it doesn't work, same connection error.
  2. Remember the 0.13.2 and 0.14.1 were started from the same environment with proxy on, but 0.13.2 works and 0.14.1 fails.
  3. Unsetting the HTTP(S)_PROXY will also affect 0.13.2.

Stop clash as system proxy and use clash's TUN mode instead ---- this is not required because as I mentioned in the last comment:

I've enabled the networkingMode=mirrored mode, which ensures the best network experience when developing in WSL2. With clash proxy enabled on Windows, you can use the clash proxy with no extra steps right in WSL2

...which means as long as I enabled Clash as system proxy, WSL2 will have proxy support transparently, no need to manully config anything else in WSL2. And only with the proxy on, I will be able to connect to OpenAI and Claude endpoint from my WSL2 environment:

➜  docker git:(main) wget -q --spider https://claude.ai && echo "connected" || echo "not connected"
connected
@Ynewtime commented on GitHub (Dec 20, 2024): > The log shows that your dify is still using the proxy setting. `2024-12-20 11:26:27 2024-12-20 03:26:27,092.092 WARNING [Dummy-1] [version.py:37] - Check update version error: HTTPSConnectionPool(host='updates.dify.ai', port=443): Max retries exceeded with url: /?current_version=0.14.1 (Caused by ProxyError('Unable to connect to proxy', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f64e2e2d9d0>: Failed to establish a new connection: [Errno 111] Connection refused'))).` > > Make sure you unset the HTTP_PROXY and HTTPS_PROXY, all upper case. You can also try the following: > > * Stop clash as system proxy and use clash's TUN mode instead. *"Make sure you unset the HTTP_PROXY and HTTPS_PROXY, all upper case"* ---- this make no sense: 1. I've tried unsetting the HTTP(S)_PROXY for 0.14.1, unfortunately it doesn't work, same connection error. 2. Remember the 0.13.2 and 0.14.1 were started from the same environment with proxy on, but 0.13.2 works and 0.14.1 fails. 3. Unsetting the HTTP(S)_PROXY will also affect 0.13.2. *Stop clash as system proxy and use clash's TUN mode instead* ---- this is not required because as I mentioned in the last comment: > I've enabled the networkingMode=mirrored mode, which ensures the best network experience when developing in WSL2. With clash proxy enabled on Windows, you can use the clash proxy with no extra steps right in WSL2 ...which means as long as I enabled Clash as system proxy, WSL2 will have proxy support transparently, no need to manully config anything else in WSL2. And only with the proxy on, I will be able to connect to OpenAI and Claude endpoint from my WSL2 environment: ```sh ➜ docker git:(main) wget -q --spider https://claude.ai && echo "connected" || echo "not connected" connected ```
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 20, 2024):

  1. I assume your actions are as follows: after you unset HTTP_PROXY and HTTPS_PROXY in WSL, run docker compose up -d again, the dify containers have been recreated, but the problem persists. If that's the case, I cannot replicate your problem, although I still suspect it is proxy related.
  2. I don't quite understand your second and third points, but #11681 is not present in 0.13.2.
  3. Because with networkingMode=mirrored and autoProxy=true, WSL will automatically set the HTTP(S)_PROXY environment variable for you if you use clash as a system proxy. TUN mode achieves the same proxy function without triggering the above. I'm not suggesting that you not use a proxy. (You can set HTTP_PROXY and HTTPS_PROXY back once dify is up anyway if you want to stick with system proxy mode.)

I hope your problem gets resolved soon.

@AugNSo commented on GitHub (Dec 20, 2024): 1. I assume your actions are as follows: after you unset HTTP_PROXY and HTTPS_PROXY in WSL, run `docker compose up -d` again, the dify containers have been recreated, but the problem persists. If that's the case, I cannot replicate your problem, although I still suspect it is proxy related. 2. I don't quite understand your second and third points, but #11681 is not present in 0.13.2. 3. Because with `networkingMode=mirrored` and `autoProxy=true`, WSL will automatically set the HTTP(S)_PROXY environment variable for you if you use clash as a system proxy. TUN mode achieves the same proxy function without triggering the above. I'm not suggesting that you not use a proxy. (You can set HTTP_PROXY and HTTPS_PROXY back once dify is up anyway if you want to stick with system proxy mode.) I hope your problem gets resolved soon.
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Dec 20, 2024):

@AugNSo You are right, needs to be reverted.

@crazywoola commented on GitHub (Dec 20, 2024): @AugNSo You are right, needs to be reverted.
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@yihong0618 commented on GitHub (Dec 20, 2024):

  1. I assume your actions are as follows: after you unset HTTP_PROXY and HTTPS_PROXY in WSL, run docker compose up -d again, the dify containers have been recreated but the problem persists. If that's the case, I cannot replicate your problem though I still suspect its proxy related.
  2. I don't quite get your second and third point, but fix: fix proxy for docker #11681 is not present in 0.13.2.
  3. Because with networkingMode=mirrored and autoProxy=true, WSL will automatically set the HTTP(S)_PROXY environment for you if you use clash as system proxy. TUN mode achieves the same proxy function without triggering the above… I'm not suggesting you not to use proxy. (You can set HTTP_PROXY and HTTPS_PROXY back once the container is up)

Hope your problem get resolved soon.

nice explain!

@yihong0618 commented on GitHub (Dec 20, 2024): > 1. I assume your actions are as follows: after you unset HTTP_PROXY and HTTPS_PROXY in WSL, run `docker compose up -d` again, the dify containers have been recreated but the problem persists. If that's the case, I cannot replicate your problem though I still suspect its proxy related. > 2. I don't quite get your second and third point, but [fix: fix proxy for docker #11681](https://github.com/langgenius/dify/pull/11681) is not present in 0.13.2. > 3. Because with `networkingMode=mirrored` and `autoProxy=true`, WSL will automatically set the HTTP(S)_PROXY environment for you if you use clash as system proxy. TUN mode achieves the same proxy function without triggering the above… I'm not suggesting you not to use proxy. (You can set HTTP_PROXY and HTTPS_PROXY back once the container is up) > > Hope your problem get resolved soon. nice explain!
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@yihong0618 commented on GitHub (Dec 20, 2024):

It's true that living in mainland China comes with a lot of internet knowledge.........

@yihong0618 commented on GitHub (Dec 20, 2024): It's true that living in mainland China comes with a lot of internet knowledge.........
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@gaoyuexit commented on GitHub (Dec 23, 2024):

I have the same question.

image
@gaoyuexit commented on GitHub (Dec 23, 2024): I have the same question. <img width="710" alt="image" src="https://github.com/user-attachments/assets/e8de6ed5-27bb-4372-81de-4586d40bc292" />
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 23, 2024):

@gaoyuexit the latest code has already fixed the issue.

@AugNSo commented on GitHub (Dec 23, 2024): @gaoyuexit the latest code has already fixed the issue.
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@gaoyuexit commented on GitHub (Dec 23, 2024):

@gaoyuexit the latest code has already fixed the issue.

I am using the latest code, maybe it's my own problem?
Is there any documentation for using Clash proxy?

@gaoyuexit commented on GitHub (Dec 23, 2024): > @gaoyuexit the latest code has already fixed the issue. I am using the latest code, maybe it's my own problem? Is there any documentation for using Clash proxy?
yindo commented 2026-02-21 18:19:51 -05:00
Author
Owner
Copy Link
Copy Source

@Ynewtime commented on GitHub (Dec 24, 2024):

It works now.

With the #11906 fix, now 0.14.1 can connect to OpenAI endpoint, same as 0.13.2 (in China Mainland, enable WSL2 mirrored networkingMode and Clash proxy).

Kudos to the team!

@Ynewtime commented on GitHub (Dec 24, 2024): It works now. With the #11906 fix, now 0.14.1 can connect to OpenAI endpoint, same as 0.13.2 (in China Mainland, enable WSL2 mirrored networkingMode and Clash proxy). Kudos to the team!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#7290
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?