mirror of
https://github.com/langgenius/dify-official-plugins.git
synced 2026-07-22 01:55:27 -04:00
xinference, PluginInvokeError Invalid URL 'SF5cd.../v1/embeddings': No scheme supplied #372
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 @R1310328554 on GitHub (Jun 16, 2025).
Self Checks
Dify version
1.3.1
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
I've download the dify ,and run it using docker compose. I added some datasets and configed the llm / embeddding /rerank models provided by xinference . It's all fine.
Then I move all the files /folders within dify , including the docker folder , to another directory. Then something weird happends: the dify's Xorbits Inference plugin seems cannt work now.
When I try to hitTest my datasets, It show out me with the following error:
[xinference] Error: PluginInvokeError: {"args":{"description":"[models] Error: Invalid URL 'SFlCU/v1/embeddings': No scheme supplied. Perhaps you meant https://SFlCU..../v1/embeddings?"},"error_type":"InvokeError","message":"[models] Error: Invalid URL 'SFlCU/v1/embeddings': No scheme supplied. Perhaps you meant https://SFlCU/v1/embeddings?"}SFlCU.... is shortened for SFlCUklEOl8xAsb3cyv8sZHwjPV/s9ohXwJzYbdoFZv4RwkJ9NPnO/AHQWgIqnbBQju2QRWHwf9KkfZgN+LkyMty3z/Kq/KVMNqJEMdX8PCFV4sZdxw8KC0vNBEnhuYDTarJPVBYAvVPHLK1gQirxviCKrIGJB8ruP2515lenNz/GcmaHZKpr8oS9SyOqYsdru0+VbtRMNoWWC3KOBOhO9Yh3b3d1DDGVF/TKqBPdlqNuJM612iLEy6tDQKYeW/bsAv+M3aci926Juk0puJ8kqarw6E2T9ciVUx3RVr+3QQsCz/9yFOFPZbkhXZVxXEy//ElndpPy+ehIBQDiAk34R3EmDLUOR2RFoCsH9TvbEuywcvUdaULeXqZw+ufts1ODIYO93xPEh6OYYmg0Xg/njBlkeLlHKCAXL+GyEBS0LY=
which is actually part of the encrypted_config of provider_models table : {"server_url": "SFlCUklE..GyEBS0LY=", "model_uid": "bge-large-zh-v1.5", "invoke_timeout": "60", "max_retries": "3", "max_tokens": 512}
✔️ Expected Behavior
hitTesting and dify ai chat with correct result, no errors tips show in the web ui.
❌ Actual Behavior
@dosubot[bot] commented on GitHub (Jun 16, 2025):
Hi @R1310328554! I'm Dosu and I’m helping the dify team.
The error you're seeing is likely caused by a problem with decrypting the server_url for your xinference provider after moving the Dify files. This usually happens if the encryption keys or config files required for decryption are missing, inaccessible, or mismatched in the new directory. As a result, the plugin tries to use the encrypted string as a URL, which leads to the "No scheme supplied" error.
To fix this, make sure that:
If you changed any container names or volumes, double-check that there are no conflicts or duplicate containers accessing the same data, as this can also cause corruption or config issues. When running in Docker, using http://host.docker.internal for internal connections can help resolve some network-related config problems as well"https://github.com/langgenius/dify/issues/18274""https://github.com/langgenius/dify/issues/15933".
If you restore the original encryption key and config environment, the plugin should be able to decrypt the server_url and function normally.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
SECRET_KEY in the .env file is present, I did not modify it, neither changed any container names or volumes . How can i restore the original encryption key and config environment? should i regenerate the SECRET_KEY in the .env file? @dosu
@dosubot[bot] commented on GitHub (Jun 16, 2025):
You should not regenerate the SECRET_KEY in your .env file—doing so will prevent decryption of any previously encrypted configs. If your SECRET_KEY is unchanged, the next thing to check is that the privkeys directory (which stores tenant-specific private RSA keys) was also moved and is accessible in your new setup. These private keys, along with the database (which holds the public keys), are required to decrypt provider and plugin credentials. If the privkeys directory or its contents are missing or corrupted, decryption will fail even if the SECRET_KEY is correct. Make sure both the privkeys directory and your database are intact and mapped correctly in your Docker setup.
The SECRET_KEY is mainly used for JWT and signatures, not for decrypting provider configs—that's handled by the RSA keys in privkeys and the database public keys. Restoring those is what will resolve your issue, not regenerating the SECRET_KEY.
Reference
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
@dosu, I feel it could be my fault , not sure. I remembered that when i moving the files / folders in dify , it could be missing some files startswith a dot, since the 'mv ' command do not move the hidden files . So, what can i do if i really changed the SECRET_KEY
@dosubot[bot] commented on GitHub (Jun 16, 2025):
If you changed the SECRET_KEY in your .env file, there’s unfortunately no way to decrypt any data (like provider configs or credentials) that was encrypted with the old key—unless you have a backup of the original SECRET_KEY. Dify does not provide a recovery or migration tool for this scenario. The SECRET_KEY is essential for verifying JWTs and signatures, and must remain unchanged to access previously encrypted data; regenerating it breaks access to all existing encrypted configs and sessions api/.env.example.
If you don’t have a backup of the original key, you’ll need to reconfigure your providers and secrets from scratch after setting a new SECRET_KEY. For future moves, always ensure you copy hidden files (like .env and the privkeys directory) using commands such as
cp -a .* *orrsync -ato avoid missing critical configuration .gitignore docker/README.md.If you do have a backup of the original SECRET_KEY, restore it in your .env file and restart your containers—your encrypted configs should work again. Also, make sure the privkeys directory is present and intact, as it’s required for decrypting provider/plugin credentials api/libs/rsa.py.
For best practices: always back up your .env and privkeys directory before moving or upgrading your deployment. Missing or changing either will result in permanent loss of access to encrypted data.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
@dosu which is the 'encrypted data' , list them all. how can i find it ? did it has any way to deencrypt them ?
@dosubot[bot] commented on GitHub (Jun 16, 2025):
The main types of encrypted data in Dify are provider credentials and sensitive plugin tokens—these are stored in fields like encrypted_config in the provider_models table and similar places for plugins. You can find them in your database; the encrypted values look like long, random strings (not readable URLs or tokens).
Dify uses RSA encryption for these fields, with tenant-specific private keys stored in the privkeys directory and public keys in the database. If you lose the privkeys or change the keys, there’s no way to decrypt the data—restoring the original privkeys and database is the only way to regain access. The SECRET_KEY in .env is not used for this encryption; it’s for JWT/session signing only. There’s no built-in tool to decrypt or recover encrypted data if the keys are lost or changed—recovery is only possible from a backup of the original keys and database.
See code reference
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
@dosu , how can i reconfigure your providers and secrets from scratch? does it mean i have to remove the dify all ,and re install by clone the it again ?
@dosubot[bot] commented on GitHub (Jun 16, 2025):
You don't need to remove or reinstall Dify to reconfigure providers and secrets from scratch. Just log in to the Dify web UI (as admin), go to the provider or plugin management section, and delete or update the broken provider/plugin configs. Then, add new providers and secrets with your current credentials—Dify will encrypt and store them using your present keys. This will overwrite any undecryptable or invalid configs in your database.
Make sure your privkeys directory and database are intact and properly mapped in your Docker setup, as these are required for encryption and decryption. For future moves, always back up your .env file and privkeys directory to avoid losing access to encrypted data. You can refer to the .env.example file for configuration templates if you need to reset any environment variables or storage settings .env.example.
No need to clone or reinstall—just re-register your providers and secrets through the UI or API, and you'll be set.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
@dosu, i've deleted the xinference plugin， and re added and reconfiged it , but i got the same error still , seems nothing changed . I very sad.
@dosubot[bot] commented on GitHub (Jun 16, 2025):
If deleting and re-adding the xinference plugin didn't fix the error, it's likely that some stale or undecryptable credentials are still in your database, or the privkeys directory is missing or mismatched. To fully reset:
If you still see the error after this, double-check that your privkeys directory matches your current database and that you didn't lose any hidden files during the move. If the privkeys are lost or mismatched, you will need to reconfigure all providers from scratch, as old encrypted configs can't be recovered without the original keys (reference).
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
what is the privkeys directory, where is it? @dosu , list and explain all the tables in dify
@dosubot[bot] commented on GitHub (Jun 16, 2025):
The privkeys directory stores tenant-specific private RSA keys used to decrypt sensitive provider and plugin credentials in Dify. Each tenant has its own key at privkeys/{tenant_id}/private.pem. This directory is critical—if it's missing or mismatched, Dify can't decrypt or re-encrypt provider configs. In a typical Docker/local setup, privkeys is inside your mapped storage directory or volume; with cloud storage, it's in your configured bucket. Always back it up along with your .env file to avoid losing access to encrypted data.
See code reference
Dify's database has many tables, each serving a specific function. Here are the main ones:
Each table has fields relevant to its function, like encrypted_config for provider credentials, or content and status for messages and documents. If you need details on a specific table or field, let me know!
Full schema reference
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
I've installed a new xinference at 192.168.15.10:9997 and a embedding / rerank / llm models with same names in it, then i changed the url from from the original http://192.168.100.1:9997/ to http://192.168.15.10:9997/ , then I works , no 'No scheme supplied' any more!!
So, i can't understand why it just works. it seems there are some caches with the ip 192.168.100.1, but i can't find where is it, in which table. Even i deleted all the table data of provider_models and provider_model_settings.
the providers table is allways empty, other tables seems to no relation with models regarding to RAG. @dosu
@dosubot[bot] commented on GitHub (Jun 16, 2025):
What likely happened is that Dify was still referencing a stale or undecryptable config for the old IP (192.168.100.1) somewhere in its in-memory state or plugin cache, even after you deleted the provider_models and provider_model_settings table data. Dify stores provider and model URLs (including for plugins like xinference) in the provider_models table, and changes should take effect immediately unless there’s an explicit cache or the app/plugin wasn’t fully restarted after DB changes. There’s no persistent file-system cache for provider URLs—everything is in the DB or in-memory of the running app or plugin process, which is cleared on restart reference.
When you pointed to a new xinference instance at a new IP and updated the URL, you forced Dify to use a fresh, valid config, which resolved the error. If you see the providers table empty, that’s normal for some setups—Dify mainly uses provider_models for model-level configs, especially for RAG and plugin workflows reference.
If you ever see similar issues, make sure to fully restart all Dify services and plugin daemons after DB or config changes to clear any in-memory state. There’s no hidden persistent cache for IPs or URLs outside the DB and memory.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
what does ./docker/volumes/app/storage/privkeys used for ? How does it work?
Does it have relations with the models or plugins ? @dosu
@dosubot[bot] commented on GitHub (Jun 16, 2025):
The ./docker/volumes/app/storage/privkeys directory stores tenant-specific private RSA keys that Dify uses to decrypt sensitive credentials for providers (like model endpoints) and plugins. Each tenant has its own private key at privkeys/{tenant_id}/private.pem. When you add or use a provider or plugin that needs to store secrets (such as API keys or URLs), Dify encrypts those values in the database using RSA; the private key from privkeys is required to decrypt them at runtime. If this directory is missing or mismatched, Dify can't read or write provider or plugin credentials, which will break model and plugin functionality reference reference.
Always back up this directory before moving or upgrading your deployment. It is directly related to models and plugins because it controls access to their encrypted configs.
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 16, 2025):
Does xinference caches the privkeys or something like that ? @dosu
@dosubot[bot] commented on GitHub (Jun 16, 2025):
Xinference does not cache privkeys or have access to them. Dify centrally manages all private key decryption and caching using Redis (for 120 seconds per tenant), but this is handled only in Dify’s core encryption library—not at the plugin or provider level. Plugins like xinference only ever see decrypted config data and never receive, store, or cache private keys themselves. This design keeps sensitive key material isolated and secure, and any caching is short-lived and never exposed to application or plugin code.
Reference
To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@R1310328554 commented on GitHub (Jun 25, 2025):
WTF, it happens again, the same error , exactly ! I did nothing. @dosu
@houliangxue commented on GitHub (Jun 30, 2025):
大哥和机器人聊这么久
@dosubot[bot] commented on GitHub (Aug 21, 2025):
Hi, @R1310328554. I'm Dosu, and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale.
Issue Summary:
Next Steps:
Thank you for your understanding and contribution!