最近有小伙伴們反應了開始節(jié)點上傳文件后，文檔提取器節(jié)點報錯問題，這個問題之前是有小伙伴提出來過的，當時的解決方案我給忘了，然后就和大家一起研究了下這個問題，并給出解決方案。
一、問題重現(xiàn)
下面我們先來看看這個Demo:
就是很簡單的一個開始節(jié)點后接文檔提取器，開始節(jié)點有一個必填參數(shù)我命名為one_file，實際上就是一個單文件，然后上傳文件類型選擇的是URL類型，如下圖：
然后文檔提取器節(jié)點就更簡單，輸入變量選擇開始節(jié)點的one_file變量即可，就相當于選擇這個文件：
結束節(jié)點就不用管了，不影響操作，也就不貼出來了。
好了，整個demo的工作流節(jié)點就這些，設置什么的上面也貼出來很清楚，那么我們就在編輯頁面預覽一下，上傳一個文件試試
點擊預覽后會讓我們粘貼文件鏈接，然后跟著頁面把上面的url貼進去就點擊按鈕就開始上傳文件了：
等上傳完文件，會展示文件的類型和大小等信息，代表識別到了這個文件類型，因為我們后面用的是文檔提取器，不支持圖片，所以這里就選擇的是一個docx的文檔，如果上傳的是圖片則會顯示圖片的縮略圖。
然后我們就開始往下走，在預覽頁面下面的輸入框隨便輸入文字點擊發(fā)送按鈕，我輸入的是開始，然后整個工作流開始運行，隨即就顯示報錯信息，如下圖所示：
報錯信息也提供了錯誤信息的參考鏈接，其實就是這個文件的url不規(guī)范導致報錯，下面看看報錯的詳細截圖：
我在做這個操作的時候，打開了瀏覽器的開發(fā)者模式，可以看到我們操作對應的接口【run】的一個信息是失敗的，狀態(tài)碼是400：
我們看到返回的錯誤信息就是上面那張報錯的信息內(nèi)容：
造成這個報錯的原因我們之前就說了是url不規(guī)范導致的錯誤，我們看這個接口調(diào)用時候的傳參就發(fā)現(xiàn)了url這個參數(shù)不是一個正常的http開頭的鏈接，而是一個相對路徑，如下圖所示：
好了，到這兒我們就已經(jīng)找出了問題所在，是因為url并不是一個規(guī)范的http/https開頭的鏈接就導致系統(tǒng)的校驗就無法通過，從而就報的是這個參數(shù)不規(guī)范的錯誤。
二、解決方案
上面我們已經(jīng)重現(xiàn)了問題并找到了導致問題的原因，那么下面我們就一起來看看如何解決吧！
我們首先找到.env這個配置文件，打開后找到FILES_URL這個配置項，這個配置項默認是空的，如下：
我們給填寫上對應的url即可，我使用的機器對應的域名，如果你們部署的時候沒有調(diào)整過端口，使用Docker啟動的，那可以填寫下面這個url：
http://host.docker.internal
我在之前的一篇文章里講過調(diào)整過端口相關的一個配置項的更改，有興趣的可以移步去看看《Dify更改默認端口及發(fā)布應用后Nginx 404錯誤解決方案》
更改完配置項后記得保存，然后執(zhí)行下面命令：
先停用：
dockercompose down
然后啟動：
dockercompose up -d
啟動后，我們再去剛才的Demo中看看。
我們按照剛才的步驟在走一遍，還是先粘貼文件鏈接，然后點擊按鈕，再次之前我們打開開發(fā)者工具，可以看到調(diào)用了upload接口，我們可以看到文件上傳后返回的數(shù)據(jù)中，url已經(jīng)是一個正常的url了：
然后我們繼續(xù)輸入文字后發(fā)送，可以看到之前我們調(diào)用的run接口這回正擦灰姑娘了，發(fā)送的參數(shù)中url也是帶http的
之后整個流程也就結束了，整個工作流都是正常的沒有再報錯誤信息了。
這個問題是很多人會忽略的問題，其實解決起來很簡單，希望可以幫到同樣遇到這樣問題而不知道如何解決的小伙伴們！
