mirror of
https://github.com/langgenius/dify-docs.git
synced 2026-07-22 04:15:24 -04:00
[DOCS]: fail to call API to add Chunks to a Document in local Dify #277
Reference in New Issue
Block a user
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?
Originally created by @ThomosShen on GitHub (Nov 26, 2025).
Type of Documentation Change
Error/Typo fix
Documentation Page URL or Path
No response
Current Content
Suggested Changes
As shown above, I tried to use online tools in dify to call call api to add Chunks to a Document in my local Dify, but it failed no matter the api base url is http://160.1.39.31:1003/v1 or http://localhost:1003/v1. And i also tried to add chunk in my dify and it works, is anything wrong in api base url? (FYI, I update the port number to 1003)
Reason for Change
No response
Code of Conduct
@dosubot[bot] commented on GitHub (Nov 26, 2025):
The "invalid URL" error when calling the API to add chunks in local Dify is almost always caused by frontend or client-side URL validation, not by the backend API itself. Dify's frontend checks that the API base URL is a well-formed HTTP/HTTPS address and may reject URLs that use
localhostor private IPs, especially in Docker or containerized setups. If Dify is running in Docker,localhostrefers to the container itself, not your host machine, so the API may not be reachable that way. Instead, use your machine's LAN IP (likehttp://160.1.39.31:1003/v1) orhost.docker.internalif supported by your environment, and make sure the port is open and mapped correctly. Always include the full scheme (http://orhttps://) in the URL and verify you can reach the API from inside the container (for example, withcurl).If you still see "invalid URL" errors, double-check that the API base URL is correct, the port is accessible, and you are not using curly braces
{}in the path—replace them with actual IDs. Also, ensure your Authorization header is set asBearer <token>. For more details and troubleshooting steps, see this discussion and recent frontend validation changes.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@ThomosShen commented on GitHub (Nov 26, 2025):
@.*** https://go.dosu.dev/dosubot.*Dear dosu,
Thanks for your technical support, I tried to solve the issue with below
methods:
1, add chunks in my local dify directly and checked the log of nginx in
container, the log is:
�10.89.0.1 - - [27/Nov/2025:01:53:36 +0000] "POST
/console/api/datasets/30a922ff-5ced-4d44-ab6f-f305c131644a/documents/2c64b247-8dbe-4037-a79e-480ee725e612/segment
HTTP/1.1" 200 706
"http://127.0.0.1:1003/datasets/30a922ff-5ced-4d44-ab6f-f305c131644a/documents/2c64b247-8dbe-4037-a79e-480ee725e612
http://127.0.0.1:1003/datasets/30a922ff-5ced-4d44-ab6f-f305c131644a/documents/2c64b247-8dbe-4037-a79e-480ee725e612"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/125.0.0.0 http://125.0.0.0 Safari/537.36" "-"�10.89.0.1 - -
[27/Nov/2025:01:53:39 +0000] "GET
/console/api/datasets/30a922ff-5ced-4d44-ab6f-f305c131644a/documents/2c64b247-8dbe-4037-a79e-480ee725e612/segments?page=105&limit=10&keyword=&enabled=all
HTTP/1.1" 200 6491
"http://127.0.0.1:1003/datasets/30a922ff-5ced-4d44-ab6f-f305c131644a/documents/2c64b247-8dbe-4037-a79e-480ee725e612
http://127.0.0.1:1003/datasets/30a922ff-5ced-4d44-ab6f-f305c131644a/documents/2c64b247-8dbe-4037-a79e-480ee725e612"
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/125.0.0.0 http://125.0.0.0 Safari/537.36" "-"
2, Update the baseURL in web according to the log above, but still failed.
[image: image.png]
Can you help check and provide solutions?
Best Regards,
Thomos SHEN
dosubot[bot] @.***> 于2025年11月26日周三 15:35写道:
@dosubot[bot] commented on GitHub (Nov 26, 2025):
The root cause is strict frontend validation in Dify: the web UI blocks API base URLs that use localhost, 127.0.0.1, or private IPs (like 10.x.x.x, 192.168.x.x, etc.), even if your backend is reachable and working. This was made stricter in recent updates, which now use the browser’s URL constructor and explicit checks for private/local addresses, causing “invalid URL” errors before any request is sent (source, PR #27558).
To resolve this:
http://192.168.x.x:1003/v1.host.docker.internal(if supported by your OS/Docker version).http://orhttps://scheme.curlto confirm the address works from the frontend’s perspective.{}in the URL path—replace them with actual dataset and document IDs.If you still get “invalid URL” errors, please share:
This will help pinpoint any remaining network or config issues.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other