mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-21 17:45:23 -04:00
The Grok model API was added before, but after updating the API KEY, it's prompting Credentials validation failed with status code 404. #436
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 @PiscesCNYu on GitHub (Jul 10, 2025).
Self Checks
Dify version
1.5.1
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
The Grok model API was added before, but after updating the API KEY, it's prompting Credentials validation failed with status code 404.
API BASE：https://api.x.ai/v1
KEY：xai-SJal***********************************************************************bd3xg
By running the command on the server:
[root@aihost ~]# curl -H "Authorization: Bearer xai-SJal***********************************************************************bd3xgg" https://api.x.ai/v1/models
Results:
{"data":[{"id":"grok-2-1212","created":1737331200,"object":"model","owned_by":"xai"},{"id":"grok-2-vision-1212","created":1733961600,"object":"model","owned_by":"xai"},{"id":"grok-3","created":1743724800,"object":"model","owned_by":"xai"},{"id":"grok-3-fast","created":1743724800,"object":"model","owned_by":"xai"},{"id":"grok-3-mini","created":1743724800,"object":"model","owned_by":"xai"},{"id":"grok-3-mini-fast","created":1743724800,"object":"model","owned_by":"xai"},{"id":"grok-4-0709","created":1752019200,"object":"model","owned_by":"xai"},{"id":"grok-2-image-1212","created":1736726400,"object":"model","owned_by":"xai"}],"object":"list"}
The above approach works, which means the API BASE is not incorrect. However, since it was previously added, when directly saving the original configuration again, it still prompts Credentials validation failed with status code 404.
It now appears to be caused by some issue in Dify.
✔️ Expected Behavior
No response
❌ Actual Behavior
No response
@dosubot[bot] commented on GitHub (Jul 10, 2025):
The 404 error during Grok API credential validation in Dify (even though curl works on the host) is almost certainly caused by Docker's Squid-based SSRF proxy blocking outbound requests to api.x.ai. By default, the proxy only allows a small set of domains, so requests to Grok/x.ai are denied inside the container, resulting in a 404 error from Dify—even if your API key and endpoint are correct.
To fix this, edit your Squid proxy config (usually at
docker/ssrf_proxy/squid.conf.template) and add a line like:Make sure this line appears before any
http_access deny allrule. Then restart thessrf_proxycontainer (docker compose restart ssrf_proxy), and try saving your Grok model config again in Dify. This should resolve the 404 error and allow credential validation to succeed.If you still see issues, check the Dify and proxy logs for errors and let me know what you find. For more details on how the proxy works and why this happens, see the Docker and Squid proxy configuration docs and Docker deployment README.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@PiscesCNYu commented on GitHub (Jul 10, 2025):
I added the following through the above methods:
But I still cannot save, and get the same 404 error.
What I find more interesting is that Dify 1.6.0 has the same error, but the previously configured workflows that use Grok AI's API can still connect and work normally - they just can't be updated with new APIs. All other models work fine.@dosu，@dosubot
@dosubot[bot] commented on GitHub (Jul 10, 2025):
This behavior is expected in Dify's architecture: saving or updating model provider credentials triggers a live validation request (usually to the provider's
/modelsendpoint via the plugin layer), and if that request fails (e.g., returns a 404), the update is blocked—even if existing workflows keep working with previously validated, cached credentials. Workflow executions do not re-validate credentials, so they continue to function until the config is changed or invalidated. This separation explains why your old Grok workflows work but you can't update or add new ones, while other providers are unaffected if their validation passes reference.Since your Squid ACL changes didn't resolve the 404, it's likely that the validation request is still being blocked or misrouted by the proxy, or the container is not using the updated config. Please check the Squid proxy logs during a save attempt to
.x.aito confirm if the request is allowed or denied. Also, ensure thessrf_proxycontainer was fully restarted after editing the ACL, and verify that no proxy-related environment variables are interfering inside the Dify container reference.If the logs show the request is allowed but you still get a 404, try running a curl command to
https://api.x.ai/v1/modelsfrom inside the Dify container (not just the host) to confirm network access. If that fails, the issue is still with Docker networking or proxy config. If it succeeds, check the Dify and plugin daemon logs for errors during credential validation.Let me know what you find in the proxy logs or if you need help with specific log output.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@PiscesCNYu commented on GitHub (Jul 10, 2025):
Could you provide a detailed troubleshooting plan? @dosu @dosubot
@dosubot[bot] commented on GitHub (Jul 10, 2025):
Here’s a detailed troubleshooting plan to isolate and resolve the Grok API credential validation 404 error in Dify (Docker):
Confirm Squid Proxy ACLs: Double-check your
docker/ssrf_proxy/squid.conf.templatefor the following, before anyhttp_access deny all:Restart the
ssrf_proxycontainer after changes. Check that the config is loaded by inspecting the running container’s/etc/squid/squid.conf.Check Proxy Logs: While attempting to save the Grok credentials, tail the Squid logs (
docker logs <ssrf_proxy_container>) and look for requests to.x.ai. Ensure they are not denied. If you see denies, the ACL is not effective or not reloaded.Test Network from Inside Containers:
docker exec -it <dify_container> /bin/bash) and run:Check for Proxy Environment Variables: Inside the Dify and plugin daemon containers, run
env | grep -i proxy. Unset any HTTP(S)_PROXY variables that might interfere with outbound requests.Review Dify and Plugin Daemon Logs: Look for errors during credential validation. The plugin daemon is responsible for making the actual API call and surfacing errors. A 404 here often means the request never reached the real endpoint or was blocked en route reference.
Plugin Daemon Health: Make sure the plugin daemon is running and healthy. If it’s not, Dify can’t validate credentials.
Cache and Restart: Dify caches plugin model schemas and credentials. After config changes, restart all related containers (
dify,plugin daemon,ssrf_proxy) to clear caches and reload configs reference.Recent Validation Changes: Be aware that Dify 1.5.1+ added stricter model provider validation and caching, which can block updates if the provider or credentials are not accepted, even if old workflows still work reference.
If you follow these steps and still get a 404, please share the relevant Squid and Dify/plugin logs from a failed save attempt—those will pinpoint where the request is being blocked or misrouted.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@PiscesCNYu commented on GitHub (Jul 10, 2025):
"I have removed the x.ai Grok API model, but when I try to add it again, it still shows 'Credentials validation failed with status code 404'.
I checked the request through the browser's network tab, and it directly returns:
{
"code": "invalid_param",
"message": "Credentials validation failed with status code 404",
"status": 400
}"
@dosu @dosubot
@dosubot[bot] commented on GitHub (Jul 10, 2025):
This 404 error is a known issue in self-hosted Dify Docker setups: the plugin_daemon service sometimes fails to handle the model credentials validation endpoint correctly, especially after removing and re-adding a provider. This can happen even if curl works on the host, because Dify’s validation runs inside the plugin_daemon container, which may have different network/proxy settings or cache state. The error is surfaced as a 400 with an "invalid_param" code, but the root cause is usually a 404 from the internal plugin_daemon call reference.
To troubleshoot:
/plugin/{id}/dispatch/model/validate_model_credentialsand any 404 or related errors.dify,plugin_daemon,ssrf_proxy) are restarted after config changes to clear any stale cache or proxy rules.http_access denyrules.This issue is not related to your API key or endpoint, but to how Dify’s plugin_daemon validates credentials internally. Reviewing the logs is the fastest way to isolate the problem.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@PiscesCNYu commented on GitHub (Jul 10, 2025):
The issue has been resolved—just update the x.ai Dify plugin.@dosu @dosubot