徹底解決 Unsupported filling mode（MT5錯誤10030）

徹底解決 Unsupported filling mode（MT5錯誤10030）

昨天為止都在其他經紀商正常運作的EA，一換到新帳戶後，Expert分頁就出現一堆 Unsupported filling mode 或 OrderSend error 10030，導致完全無法下單 — 這是MT5使用EA時最常見的經紀商轉移問題之一。並不是EA壞了，也不是帳戶有問題。原因只是訂單的「成交方式（filling mode）」在新經紀商的該交易品種上不被允許而已。

本文針對使用MT5的EA使用者，以及用MQL5開發EA的開發者，將 TRADE_RETCODE_INVALID_FILL（10030）的本質・FOK/IOC/RETURN的意義・30秒內完成的確認方法・程式碼層面的根本對策整理成一篇終極指南。若需要錯誤代碼全覽，請參考 MQL5 / MT5 錯誤代碼對策綜合指南。

---

何謂10030（TRADE_RETCODE_INVALID_FILL）

OrderSend() 的結果會存入 MqlTradeResult.retcode。其中回傳的 10030 = TRADE_RETCODE_INVALID_FILL，代表「請求中指定的 type_filling（成交方式）在該交易品種上不被允許」，這是伺服器端的拒絕通知。

意義: 指定的成交方式（filling type）不受支援
常數: TRADE_RETCODE_INVALID_FILL
數值: 10030
顯示: Unsupported filling mode / Invalid order filling type

// 日誌中可見的典型輸出範例
2026.07.07 09:15:32.441 EA_NAME EURUSD,M15: OrderSend error 10030
2026.07.07 09:15:32.441 EA_NAME EURUSD,M15: failed market buy 0.10 EURUSD [Unsupported filling mode]

重點是，這與資金、手數、價格完全無關。10030純粹是請求中 MqlTradeRequest.type_filling 這一個欄位的問題，只要修正這一點，同樣的訂單就能直接通過。

成交方式（type_filling）的四種類型

MQL5的 ENUM_ORDER_TYPE_FILLING 有四個數值。

常數	俗稱	意義
ORDER_FILLING_FOK	Fill or Kill	僅在可全額成交時才執行。若1手訂單只有0.7手的流動性，則整筆訂單取消
ORDER_FILLING_IOC	Immediate or Cancel	能成交的部分立即執行，剩餘部分取消。若只成交0.7手，剩下0.3手就會消失
ORDER_FILLING_RETURN	Return	執行可成交的部分，剩餘數量以掛單形式留在盤口（等待後續成交）。用於交易所型執行
ORDER_FILLING_BOC	Book or Cancel	僅在能掛入盤口（被動等待）時才接受，若價格會立即成交則拒絕。專用於限價/停損限價單（較新版本新增）

一般外匯EA實際使用的幾乎都是 FOK 或 IOC。RETURN則用於股票、期貨等交易所執行（Exchange execution），BOC是想強制做為掛單（maker order）的特殊用途。

為何會判定為「不正確」— SYMBOL_FILLING_MODE

哪些成交方式會被接受，取決於經紀商針對每個交易品種設定的旗標（SYMBOL_FILLING_MODE）。可用MQL5如下讀取。

long flags = SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE);
// 若設有 SYMBOL_FILLING_FOK 旗標，則可使用 FOK
// 若設有 SYMBOL_FILLING_IOC 旗標，則可使用 IOC

SYMBOL_FILLING_MODE 是位元旗標，包含FOK與IOC的允許狀況（若兩者皆允許，則兩個旗標都會被設置）。RETURN不包含在此旗標中，是否可用取決於該交易品種的執行模式（後述）。

也就是說，10030的結構很單純：

EA送出的type_filling ∉ 該交易品種允許的成交方式 → 10030

僅此而已。

---

為何偏偏在「更換經紀商當天」出現

10030之所以被稱為「經紀商轉移的經典錯誤」，理由如下。

1. 允許的成交方式因經紀商、交易品種而異。 有些經紀商只允許外匯品種使用FOK，另一些只允許IOC，還有一些兩者都允許。即使在同一經紀商內，外匯與CFD、股票的設定不同也很常見。
2. 許多EA將type_filling寫死在程式碼中。 例如寫成 request.type_filling = ORDER_FILLING_FOK; 的EA，在允許FOK的經紀商A上可以運作許多年。因為在作者的環境下能正常運作，這個問題就不會被當作臭蟲，就這樣被發布出去。
3. 若轉移目標的經紀商B不允許FOK，則從第一筆下單就會全部失敗。 這在回測中往往不會出現（測試器的行為比實際伺服器寬鬆），因此常常是「轉到實盤帳戶的當天」才顯現出來。

也就是說，10030與其說是EA的臭蟲，不如說是「對環境前提的武斷假設」被揭露出來。反過來說，只要修改成讀取交易品種的允許旗標並動態選擇，就能做成在任何經紀商都能運作的EA（詳見後述程式碼）。

與執行模式（SYMBOL_TRADE_EXEMODE）的關係

交易品種除了成交方式之外，還有執行模式，這會影響哪種成交方式才有意義。

執行模式	常數	典型情況	成交方式傾向
Instant	SYMBOL_TRADE_EXECUTION_INSTANT	部分外匯（DD型較多）	以指定價格執行。屬於FOK/IOC＋重新報價的模式
Market	SYMBOL_TRADE_EXECUTION_MARKET	多數外匯/CFD（NDD型）	市價執行。FOK或IOC（依經紀商設定而定）
Exchange	SYMBOL_TRADE_EXECUTION_EXCHANGE	股票・期貨	掛入盤口的執行方式。基本上使用RETURN
Request	SYMBOL_TRADE_EXECUTION_REQUEST	舊式	請求式執行（目前少見）

嚴格來說，允許的組合方式取決於經紀商的伺服器設定，但實務上只要記住「外匯/CFD的Market執行用FOK或IOC，交易所型則以RETURN為前提」就已經足夠。執行模式也可透過 SymbolInfoInteger(_Symbol, SYMBOL_TRADE_EXEMODE) 來確認。

---

先花30秒排查

① 查看交易品種允許的方式（MT5畫面）

打開報價視窗 → 右鍵點選交易品種 → 規格（Specification），查看**「成交」（Filling）**這一行。會顯示 Fill or Kill / Immediate or Cancel 或兩者皆有。若EA送出的方式沒有列在這裡，就必定是10030。

② 查看EA的輸入參數

做得好的EA通常會有 FillingType / Filling Mode 這類輸入項目。如果有，只要依照①確認的允許方式修改即可解決（不需修改程式碼）。

③ 用程式碼確認（開發者適用）

long flags = SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE);
PrintFormat("%s filling: FOK=%s IOC=%s exemode=%d",
            _Symbol,
            ((flags & SYMBOL_FILLING_FOK) != 0) ? "yes" : "no",
            ((flags & SYMBOL_FILLING_IOC) != 0) ? "yes" : "no",
            (int)SymbolInfoInteger(_Symbol, SYMBOL_TRADE_EXEMODE));

用腳本執行這段程式碼，就能一行顯示出該經紀商、該交易品種的實際允許狀況。

---

根本對策 — 讀取允許旗標並自動選擇的MQL5程式碼

10030的正確解法並非「每次轉移都手動調整」，而是讓EA自己讀取交易品種的允許旗標並自動選擇。以下是可直接套用的標準做法。

自動判斷函式

// 回傳該交易品種實際允許的成交方式
// 優先順序: FOK → IOC → RETURN（交易所型的備援）
ENUM_ORDER_TYPE_FILLING GetFillingMode(const string symbol)
{
   long flags = SymbolInfoInteger(symbol, SYMBOL_FILLING_MODE);

   if((flags & SYMBOL_FILLING_FOK) != 0)
      return ORDER_FILLING_FOK;    // 僅在可全額成交時才執行（不會部分成交）

   if((flags & SYMBOL_FILLING_IOC) != 0)
      return ORDER_FILLING_IOC;    // 僅執行可成交的部分，剩餘取消

   return ORDER_FILLING_RETURN;    // 無旗標＝交易所型等。以RETURN送出
}

在OrderSend中的用法

MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);

req.action       = TRADE_ACTION_DEAL;
req.symbol       = _Symbol;
req.volume       = lots;
req.type         = ORDER_TYPE_BUY;
req.price        = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
req.deviation    = 20;
req.magic        = MagicNumber;
req.type_filling = GetFillingMode(_Symbol);   // ← 不要寫死

if(!OrderSend(req, res) || res.retcode != TRADE_RETCODE_DONE)
{
   if(res.retcode == TRADE_RETCODE_INVALID_FILL)   // 10030
      PrintFormat("Unsupported filling mode: sent=%d, allowed flags=%d",
                  (int)req.type_filling,
                  (int)SymbolInfoInteger(_Symbol, SYMBOL_FILLING_MODE));
   else
      PrintFormat("OrderSend failed: retcode=%d", res.retcode);
}

如此一來，無論是僅支援FOK還是僅支援IOC的經紀商，同一份程式都能正常運作，轉移時就不再需要手動修改。

使用CTrade的情況

標準函式庫的 CTrade 提供了 SetTypeFillingBySymbol()，可依交易品種的允許旗標自動設定成交方式。

#include <Trade/Trade.mqh>
CTrade trade;

int OnInit()
{
   trade.SetExpertMagicNumber(MagicNumber);
   trade.SetTypeFillingBySymbol(_Symbol);   // 讀取允許旗標並自動設定
   return INIT_SUCCEEDED;
}

若因舊式寫法 trade.SetTypeFilling(ORDER_FILLING_FOK);（寫死指定）而出現10030，只要換成這一行即可解決。若想手動指定，也可將前述 GetFillingMode() 的結果傳給 SetTypeFilling()，效果相同。

使用限價單（BOC）時的注意事項

ORDER_FILLING_BOC（Book or Cancel）專用於限價・停損限價單，若指定的價格會立即成交則會被拒絕。將其用於市價單是錯誤用法，因此市價型EA不需要將BOC納入選項。

---

關於經紀商的注意事項（轉移時應重新確認）

• 成交方式的允許設定不僅因經紀商而異，即使在同一經紀商內，不同交易品種（商品分組）也可能不同。 外匯可用IOC，但股票CFD只允許RETURN，這種組合並不罕見。
• 變更帳戶類型或伺服器時，設定也可能改變。 不只是轉換經紀商，在同一經紀商內進行伺服器搬遷、帳戶類型變更、商品規格修訂之後，也可能突然開始出現10030。
• 因此，作為運用規則，養成**「只要帳戶、伺服器、交易品種其中之一發生變化，就到規格畫面（或用腳本）重新確認成交方式」**的習慣才是穩妥做法。若EA已內建自動判斷程式碼，就完全不需要這道確認手續。

由於特定經紀商「該交易品種僅支援FOK」之類的資訊會隨伺服器設定變更而過時，本文不逐一列舉。請務必以自己帳戶的交易品種規格為準進行確認。

---

優先順序檢查清單

優先度	確認項目	對策
🚨 首先	交易品種規格中的「成交」欄位與EA指定的方式是否一致	調整為允許的方式
🚨 首先	EA是否有FillingType輸入項目	僅需變更輸入即可解決（不需改程式碼）
⚠️ 接著	EA程式碼中的type_filling是否被寫死	改用 GetFillingMode() / SetTypeFillingBySymbol()
⚠️ 接著	是否曾更換經紀商、伺服器、帳戶類型	變更後務必重新確認規格
✅ 確認	執行模式（Instant/Market/Exchange）的差異	交易所型商品以RETURN為前提
🛠 開發	是否針對10030的retcode做個別處理	將送出的方式與允許旗標記錄到日誌

---

總結

• Unsupported filling mode（10030 / TRADE_RETCODE_INVALID_FILL）是當訂單的 type_filling（FOK / IOC / RETURN / BOC）在該交易品種上不被允許時，伺服器端的拒絕回應。與資金或手數無關。
• 允許的方式因經紀商、交易品種而異，因此將type_filling寫死的EA，會在轉移經紀商當天集體出現10030。這正是此錯誤的典型模式。
• 一般使用者可透過「查看交易品種規格的成交欄位 → 調整EA輸入」立即解決。開發者則可讀取 SymbolInfoInteger(SYMBOL_FILLING_MODE) 的旗標自動選擇（或使用 CTrade::SetTypeFillingBySymbol()），從根本解決問題。

有關錯誤代碼全覽，請參考 MQL5 / MT5 錯誤代碼對策綜合指南。FXEA365所提供的EA已實作成交方式的自動判斷功能，無論搭配哪家經紀商都能運作（EA一覽）。

---

常見問題

Q: 昨天還能運作的EA，換了經紀商後就出現10030完全無法下單，是EA故障嗎？

並非故障。只是EA指定的成交方式（例如FOK）在新經紀商的該交易品種上不被允許而已。請確認交易品種規格中的「成交」欄位，調整EA的輸入項目（FillingType等），或將程式碼改為自動判斷，就能恢復原本的運作。

Q: FOK 和 IOC 應該用哪一個？

若交易品種兩者皆允許，差異會顯現在「流動性不足時」。FOK若無法全額成交就整筆取消（不會產生半調子的部位），IOC則會保留能成交的部分（可能發生部分成交）。以個人外匯交易的手數規模而言，流動性不足的情況本身就很罕見，實務上兩者差異不大。像自動判斷程式碼那樣以FOK優先並無問題。

Q: 回測時不會出現，但實盤帳戶卻出現10030。

策略測試器的成交處理並未完全重現實際伺服器的設定，因此type_filling不一致的問題有時在測試中不會顯現。建議在實盤帳戶或模擬帳戶首次運作時，先對照交易品種規格的成交欄位進行確認。

Q: 明明是同一家經紀商，卻因交易品種不同而有時出現10030、有時不會。

這是正常（可能發生）的現象。成交方式的允許設定是以交易品種為單位，因此外匯貨幣對可用IOC、股票CFD僅允許RETURN，依商品分組而異的情況很常見。多品種EA務必針對每個交易品種讀取 SYMBOL_FILLING_MODE。

Q: 無法修改EA的程式碼（只有.ex5檔案），該怎麼辦？

請先確認EA的輸入參數中是否有FillingType相關的項目。若沒有，代表該EA在目前經紀商的該交易品種上無法使用。可以請作者進行對應，或改在允許該EA所預設成交方式的經紀商／帳戶類型上運作。