徹底解決 Market closed(10018 / 錯誤132)
目錄
- Market closed 是什麼(10018 與 132 的差異)
- ① TRADE_RETCODE_MARKET_CLOSED = 10018(MT5 / `OrderSend()` 的回傳代碼)
- ② ERR_MARKET_CLOSED = 132(MT4 / MQL4 的 `GetLastError()`)
- 先花30秒排查
- 成因與對策(6種模式)
- ① 週末、假日導致整個市場關閉
- ② 商品別交易時段外(每日休市)
- ③ 混淆了伺服器時間與本地時間
- ④ 商品被設為停止交易/僅限平倉(SYMBOL_TRADE_MODE)
- ⑤ 週一開盤後、或休市結束後的瞬間
- ⑥ 因新聞、事件導致交易暫停
- 用MQL5防範此錯誤的程式碼(給EA開發者)
- 確認是否在交易時段內
- 確認交易模式(SYMBOL_TRADE_MODE)
- 整合為下單前的守門機制
- 若仍然收到10018時的處理方式
- 優先順序檢查清單
- 總結
- 常見問題
- Q: 明明是平日白天卻出現 Market closed,為什麼?
- Q: 10018 與 132 有什麼不同?
- Q: 週末EA持續出現錯誤,放著不管沒關係嗎?
- Q: 加密貨幣(BTCUSD)也出現了 Market closed,不是應該能24小時交易嗎?
徹底解決 Market closed(MT5/MQL5)
當EA的日誌出現 Market closed 或 market is closed 時,「因為是假日所以理所當然」這種情況其實只佔一半。明明是平日白天卻出現,或是其他商品都能正常下單,唯獨特定商品出現此錯誤——很多人正是被這種情況困擾。
原因不僅僅是「週末」,還包括個別商品的交易時段(黃金或股價指數的每日休市)、券商伺服器時間與你本地時間的落差、商品的交易模式限制(僅限平倉等)等多種可能。本文針對使用MT5的EA使用者以及以MQL5開發EA的人,完整整理了 Market closed 的真面目、6大成因、30秒排查法、以及在程式碼層面的永久防範對策。若想查閱錯誤代碼的完整清單,請參考 MQL5 / MT5 錯誤代碼對應總整理。
本文以2026年7月當時的MT5(build 4xxx系列)為前提。交易時段時間、畫面名稱依券商與版本而異。
Market closed 是什麼(10018 與 132 的差異)
代表「市場已關閉」的代碼,在MT5與MT4(MQL4)中是不同的東西。請依照你使用的平台、以及取得數值的位置來對應解讀。
① TRADE_RETCODE_MARKET_CLOSED = 10018(MT5 / OrderSend() 的回傳代碼)
在MQL5中下單後,OrderSend() 的結果會存入 MqlTradeResult.retcode。當交易伺服器判定「該商品目前不在交易時間內」而拒絕下單時,回傳的代碼就是 10018。這並非MT5本身的內部錯誤,而是來自券商伺服器的拒絕通知。
意義: 市場關閉中(Market is closed)
常數: TRADE_RETCODE_MARKET_CLOSED
數值: 10018
// 日誌中常見的典型輸出範例
2026.07.06 23:05:11.204 EA_NAME XAUUSD,M5: OrderSend error 10018 [Market closed]
② ERR_MARKET_CLOSED = 132(MT4 / MQL4 的 GetLastError())
在MT4(MQL4)中,OrderSend() 失敗後呼叫 GetLastError() 會回傳 132。意義與10018相同,都是「市場關閉中」。若同時併用MT4版EA,同一個原因會在MT5顯示為10018、在MT4顯示為132。
意義: 市場關閉中(Market is closed)
常數: ERR_MARKET_CLOSED(MQL4)
數值: 132
實務上的對照:
| 平台 | 取得來源 | 數值 |
|---|---|---|
| MT5 (MQL5) | MqlTradeResult.retcode / CTrade.ResultRetcode() | 10018 |
| MT4 (MQL4) | OrderSend() 失敗後的 GetLastError() | 132 |
兩者的根本原因相同,都是「在伺服器的交易時段之外送出訂單(或該商品的交易受到限制)」。對策也相同,以下將一併說明。
先花30秒排查
在盲目重啟EA之前,先檢查這4項就能大致鎖定原因。
- 查看商品的交易時段 — 在報價視窗(Market Watch)中右鍵該商品 → 「規格(Specification)」→ 「交易時段」。上面會列出依星期別的可交易時間(伺服器時間)。若目前時間不在這個範圍內,答案就在這裡。
- 確認伺服器時間 — 報價視窗上方顯示的時間就是券商的伺服器時間。交易時段的判定並非依你電腦的時鐘,而是以此時間為準。與台灣時間相差數小時是很正常的。
- 確認交易模式 — 在同一個「規格」畫面中,「交易」欄位是否不是
Full access(例如Disabled/Close only等)。若是,即使在交易時段內,新單也會被拒絕。 - 改用其他商品測試 — 若EURUSD等主要外匯貨幣對可以用同一組EA/手動下單成功,就能將問題鎖定在該特定商品的交易時段/限制,而非帳戶或EA本身。
成因與對策(6種模式)
① 週末、假日導致整個市場關閉
症狀: 週六、週日,或是年末年初、聖誕節等時期出現錯誤。所有商品都會發生。
原因: 外匯市場基本上在伺服器時間週五收盤到週一開盤這段期間無法交易。假日(元旦、聖誕節等)即使是平日,也會休市或縮短交易時間。若EA因為K棒殘留處理或時間週期的關係,在週末仍嘗試下單,就會連續出現10018/132。
對策:
- 這個錯誤本身無害。市場開盤後會自然解除
- 若不想讓日誌變亂,可在EA端加入星期別、交易時段的檢查,從一開始就不送出訂單(詳見後述程式碼)
- 假日行事曆因券商而異,請確認券商公告的休市時程
② 商品別交易時段外(每日休市)
症狀: 明明是平日,但特定商品(黃金、白銀、股價指數CFD、能源等)就是會出現錯誤。而且幾乎每天都在相同時段出現。
原因: 外匯貨幣對在平日幾乎全天24小時都能交易,但貴金屬或股價指數CFD每天都有數十分鐘到數小時的休市時間(每日休市)。這是配合原始資產的交易所維護或轉倉安排而設定的,具體時段依券商與商品而異。若EA在這段休市時間下單,就會出現10018。
對策:
- 在「規格 → 交易時段」中確認該商品準確的休市時段(這裡標示的時間才是唯一正確答案,不要照單全收別人部落格上寫的時間——每家券商都不同)
- 利用EA的時間篩選功能(
TradeStartHour/TradeEndHour等)避開休市時段 - 開發者可在程式碼中檢查
SymbolInfoSessionTrade()(詳見後述)
另外,許多券商的加密貨幣(BTCUSD等)週末也能交易,但這同樣依券商而異。請勿認定「加密貨幣就該是24/7」,務必在規格畫面中確認清楚。
③ 混淆了伺服器時間與本地時間
症狀: 明明「規格中的交易時段應該還在交易時間內」,卻出現錯誤。使用海外券商時常見。
原因: 規格中標示的交易時段時間,以及MT5內顯示的時間,全部都是券商的伺服器時間。許多海外券商採用GMT+2/+3(以紐約收盤=0點為設定基準),與台灣時間相差6~7小時。台灣時間「還是週五晚上」,但伺服器時間可能已經是週六,這種落差非常典型。
對策:
- 養成以報價視窗上的時間(=伺服器時間)為判斷基準的習慣
- EA的參數(交易時間篩選等)通常規定以伺服器時間指定。請重新檢查是否誤以為是用台灣時間設定
- 在程式碼中使用
TimeTradeServer()(不要用TimeLocal()來判定交易時段)
④ 商品被設為停止交易/僅限平倉(SYMBOL_TRADE_MODE)
症狀: 在交易時段內、平日,但特定商品的新單全部被拒絕。有時只有平倉單能成功送出。
原因: 券商可以針對個別商品設定交易模式。
| SYMBOL_TRADE_MODE | 意義 |
|---|---|
SYMBOL_TRADE_MODE_FULL | 無限制(正常) |
SYMBOL_TRADE_MODE_CLOSEONLY | 僅可平倉(無法新單)。常見於即將下市或換月前的CFD等 |
SYMBOL_TRADE_MODE_DISABLED | 完全禁止交易 |
SYMBOL_TRADE_MODE_LONGONLY / SHORTONLY | 僅可做多/僅可做空 |
模擬帳戶與真實帳戶的設定也可能不同,帳戶類型不同,可交易的商品也可能不同。
對策:
- 確認「規格」畫面的「交易」欄位
- 若為
Close only,新單就別再嘗試,改為整理現有部位。若想長期使用該商品,可確認是否有換月後的其他相同商品,或不同後綴的商品名稱(例如US500.f等) - 若持續顯示
Disabled,請向券商確認該帳戶類型是否可交易此商品
⑤ 週一開盤後、或休市結束後的瞬間
症狀: 僅在週一市場開盤後的幾分鐘內,或每日休市結束後的瞬間,出現錯誤或成交遭拒。
原因: 從交易時段「開盤」的瞬間,到實際能穩定成交之間仍有一段落差。開盤剛開始時流動性稀薄、點差極端擴大,部分券商甚至在報價開始穩定流動之前不接受下單(=以市場關閉的名義拒絕)。在週一早上第一時間發出訊號的EA、或鎖定休市結束時機進場的黃金EA,特別容易碰上這個問題。
對策:
- 加入開盤後○分鐘內暫緩新單的篩選機制(例如
AvoidMondayOpen)。本站配布的EA之所以預設避開週一0-3點(伺服器時間),原因就在此 - 務必同時搭配點差篩選(
MaxSpread)。開盤剛開始的異常點差若成交,造成的損失往往比錯誤本身更嚴重 - 設計上遇到10018時不要立即重試,改為等到下一根K棒再嘗試
⑥ 因新聞、事件導致交易暫停
症狀: 重要指標公布前後,或個別商品出現異常變動時,暫時性地出現錯誤。
原因: 部分券商、商品在重大事件發生時,可能會暫時停止交易(熔斷),或限制新單。股價指數CFD有時會配合原始資產市場的熔斷機制而暫停。這段期間內的下單會被歸類為市場關閉類的拒絕。
對策:
- 這是暫時性的,過一段時間就會恢復
- 利用經濟指標篩選功能(本站EA的
UseEconomicFilter)在指標公布前後暫停新單,可同時達成避開錯誤與規避急速變動風險
用MQL5防範此錯誤的程式碼(給EA開發者)
Market closed 正確的設計方式不是「出錯後再處理」,而是在下單前先確認交易時段與交易模式,若已關閉就不送出。這樣不僅能讓日誌保持乾淨,也能避免無謂的伺服器請求與失控重試。
確認是否在交易時段內
SymbolInfoSessionTrade() 會回傳指定星期第 i 個交易時段的開始/結束時間(以伺服器時間0點起算的秒數)。為了因應有多個時段的商品(例如中間夾著每日休市的指數),需以迴圈確認所有時段。
// 判斷目前的伺服器時間是否在該商品的交易時段內
bool IsTradeSessionOpen(const string symbol)
{
MqlDateTime dt;
TimeToStruct(TimeTradeServer(), dt); // 務必以伺服器時間判定
int now = dt.hour*3600 + dt.min*60 + dt.sec; // 從0點起算的經過秒數
datetime from, to;
for(uint i = 0; SymbolInfoSessionTrade(symbol, (ENUM_DAY_OF_WEEK)dt.day_of_week, i, from, to); i++)
{
int f = (int)from; // 從0點起算的秒數
int t = (int)to; // 24:00結束時會是 86400
if(now >= f && now < t)
return true;
}
return false; // 該星期沒有對應時段(如週末)或不在任何時段內
}
確認交易模式(SYMBOL_TRADE_MODE)
// 判斷是否為可新單進場的交易模式
bool IsNewEntryAllowed(const string symbol, ENUM_ORDER_TYPE type)
{
long mode = SymbolInfoInteger(symbol, SYMBOL_TRADE_MODE);
if(mode == SYMBOL_TRADE_MODE_DISABLED) return false; // 交易已停用
if(mode == SYMBOL_TRADE_MODE_CLOSEONLY) return false; // 僅限平倉=無法新單
if(mode == SYMBOL_TRADE_MODE_LONGONLY && type != ORDER_TYPE_BUY) return false;
if(mode == SYMBOL_TRADE_MODE_SHORTONLY && type != ORDER_TYPE_SELL) return false;
return true; // SYMBOL_TRADE_MODE_FULL 等情況
}
整合為下單前的守門機制
// OnTick 內: 即使訊號成立,只要市場關閉就不送出
if(!IsTradeSessionOpen(_Symbol) || !IsNewEntryAllowed(_Symbol, ORDER_TYPE_BUY))
{
// 事先防範10018。只留下一行日誌,等待下一根K棒
return;
}
若仍然收到10018時的處理方式
由於交易時段資訊的更新時機、開盤瞬間的拒絕等因素,無法將所有漏網之魚完全排除。查看 OrderSend() 的retcode,遇到10018時不要立即重試(等到下一根K棒再試),這是鐵則。在市場關閉期間連續重試,只會讓日誌變亂,毫無幫助。
MqlTradeRequest req; MqlTradeResult res;
ZeroMemory(req); ZeroMemory(res);
// ... 組裝 req ...
if(!OrderSend(req, res) || res.retcode != TRADE_RETCODE_DONE)
{
if(res.retcode == TRADE_RETCODE_MARKET_CLOSED) // 10018
Print("Market closed. Skip and wait for the next session.");
else
PrintFormat("OrderSend failed: retcode=%d, lastError=%d", res.retcode, GetLastError());
}
老實說,在週一開盤瞬間或每日休市前後(尤其是黃金、股價指數)下單的EA,經常會遇到這個錯誤。有意識到交易時程的EA——具備交易時段確認、開盤瞬間暫緩下單、週末前收倉等機制——不僅能避免無謂的錯誤,也能規避流動性稀薄時段的不良成交。FXEA365配布的EA標準內建了**避開週一開盤(AvoidMondayOpen)、時間篩選、週末前收倉(CloseAllBeforeWeekend)**等功能。
優先順序檢查清單
| 優先度 | 確認項目 | 對策 |
|---|---|---|
| 🚨 先確認 | 現在是否為週末、假日(以伺服器時間為準) | 靜候即可,錯誤本身無害 |
| 🚨 先確認 | 是否在規格中「交易時段」範圍內 | 用時間篩選避開個別商品的休市時段 |
| ⚠️ 其次 | 是否混淆了伺服器時間與台灣時間 | 以報價視窗顯示的時間重新設定 |
| ⚠️ 其次 | 交易模式是否為 Full access | 若為 Close only / Disabled,請向券商確認規格 |
| ✅ 確認 | 是否處於開盤瞬間、或休市結束瞬間 | 暫緩○分鐘+搭配點差篩選 |
| 🛠 開發 | 下單前是否有確認交易時段/模式 | 實作 SymbolInfoSessionTrade 守門機制 |
總結
Market closed在MT5為10018(TRADE_RETCODE_MARKET_CLOSED)、MT4為132(ERR_MARKET_CLOSED)。意義相同,都是「交易時段外/交易受限期間送出的訂單」。- 除了週末外,個別商品的每日休市(黃金、指數)、伺服器時間落差、SYMBOL_TRADE_MODE限制、開盤瞬間遭拒都會導致此錯誤。若在平日發生,請先查看「規格 → 交易時段」。
- 交易時段時間依券商與商品而異。唯一正確答案是你的MT5規格畫面上顯示的時間。
- EA開發者應透過
SymbolInfoSessionTrade()+SYMBOL_TRADE_MODE+TimeTradeServer()建立下單前的守門機制,作為永久對策。收到10018時不要立即重試,應等待下一根K棒。
錯誤代碼的完整整理請參考 MQL5 / MT5 錯誤代碼對應總整理,標準內建交易時段規避、時間篩選功能的免費EA請參考 EA一覽。
常見問題
Q: 明明是平日白天卻出現 Market closed,為什麼?
原因可能是該商品特有的休市時段(每日休市),或是該商品的交易模式限制。黃金、白銀、股價指數CFD即使在平日,每天也都有無法交易的時段。請在報價視窗中右鍵該商品 → 「規格」→ 確認「交易時段」與「交易」欄位。
Q: 10018 與 132 有什麼不同?
只是平台不同,意義完全相同。10018(TRADE_RETCODE_MARKET_CLOSED)是MT5的 OrderSend() 回傳代碼,132(ERR_MARKET_CLOSED)是MT4(MQL4)的 GetLastError() 數值。對策也相同。
Q: 週末EA持續出現錯誤,放著不管沒關係嗎?
實際上不會造成損害。市場開盤後就會自然停止。但如果在意日誌變亂、或推播通知一直響個不停,根本的解決方法是在EA端加入星期別/交易時段檢查,讓下單本身直接跳過(請參考本文的程式碼)。
Q: 加密貨幣(BTCUSD)也出現了 Market closed,不是應該能24小時交易嗎?
加密貨幣CFD週末是否能交易依券商而定。有些券商週末會停止交易,或設有短暫的維護休市時間。與外匯貨幣對相同,請透過「規格 → 交易時段」確認你所使用券商的實際可交易時間。
相關文章
📧 漲價預告 + 免費5天郵件課程
所有EA目前均為首發價,並將隨銷量階梯式上調。在每次漲價前收到通知,另有每日一封郵件:自動交易本質、正確解讀回測、券商選擇技巧。
※ 嚴格保護隱私。可隨時取消訂閱。