After upgrading from version 1.10.1-fix.1 to version 1.15.0, a large number of Reached maximum retries for URL errors occurred in the originally normal workflow

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [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, otherwise it will be closed.
- [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
- [x] 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

After upgrading from version 1.10.1-fix.1 to version 1.15.0, a large number of Reached maximum retries for URL errors occurred in the originally normal workflow,

It's not that the network is down. Instead, when multiple requests are initiated, some of them always encounter an error similar to the following. The same chatflow did not have this issue before. Could it be caused by the new version of ssrf_proxy? Can it be completely closed? I am an offline deployment security environment.

My http interface request response time is relatively longer, but the same configuration operates normally under version 1.10.1

Reached maximum retries for URL http://10.xx.xx.xx:5000/dify/read_excel

logs:
```
api-1 | 2026-07-14 10:51:31.720 INFO [Dummy-122] [_client.py:1025] 2992c2fa40085ab3b4e2f447908c521e - HTTP Request: GET `https://xxx.xxx.xxx.xxx/dify/read_excel?file_path=%2Fmnt%2Fuser_data%2Fuploads%2F29b5390207d28bfc68649088c720884f.xlsx&sql=SELECT+MIN%28%E5%BC%80%E5%A7%8B%E6%97%B6%E9%97%B4%29+AS+%E9%A6%96%E6%9D%A1_%E5%BC%80%E5%A7%8B%E6%97%B6%E9%97%B4%2C+MIN%28%E7%BB%93%E6%9D%9F%E6%97%B6%E9%97%B4%29+AS+%E9%A6%96%E6%9D%A1_%E7%BB%93%E6%9D%9F%E6%97%B6%E9%97%B4%2C+MAX%28%E5%BC%80%E5%A7%8B%E6%97%B6%E9%97%B4%29+AS+%E5%B0%BE%E6%9D%A1_%E5%BC%80%E5%A7%8B%E6%97%B6%E9%97%B4%2C+MAX%28%E7%BB%93%E6%9D%9F%E6%97%B6%E9%97%B4%29+AS+%E5%B0%BE%E6%9D%A1_%E7%BB%93%E6%9D%9F%E6%97%B6%E9%97%B4+FROM+data%3B&orient=list` "HTTP/1.1 502 Bad Gateway"
api-1 | 2026-07-14 10:51:31.722 WARNING [Dummy-122] [ssrf_proxy.py:206] 2992c2fa40085ab3b4e2f447908c521e - Received status code 502 for URL `https://xxx.xxx.xxx.xxx/dify/read_excel` which is in the force list
api-1 | 2026-07-14 10:51:31.723 WARNING [Dummy-122] [node.py:235] 2992c2fa40085ab3b4e2f447908c521e - http request node 1779776953647 failed to run: Reached maximum retries for URL `https://xxx.xxx.xxx.xxx/dify/read_excel`
```

### ✔️ Expected Behavior

It can be consistent with the performance in version 1.10.1, and the http node is normal

### ❌ Actual Behavior

The http node is running unstably, with Reached maximum tries occurring from time to time, and the response feels longer than before.

Start with ssrf_proxy.py around the logged 502 handling and node.py around the HTTP request retry path. Reproduce the workflow upgrade scenario with the slow self-hosted endpoint, then compare the retry behavior with version 1.10.1. Done means the HTTP node handles intermittent or slow responses reliably without the unexpected maximum-retries error.

Written by the indexing model from the issue text.