EA-parameters gewijzigd maar niet actief? Controleer configuratieversie en VPS-synchronisatie

Auteur: Thomas｜EA en platformpraktijk｜8 oktober 2026

Als u de parameters van een EA wijzigt, lijkt het in de lokale interface misschien al actief, maar op afstand draait mogelijk nog de oude configuratie. Het probleem zit vaak in het niet op elkaar afgestemd zijn van de runtime-omgevingen. Dit artikel geeft een methode voor het vastleggen van parameterupdates om de daadwerkelijk draaiende versie te controleren; of een specifiek programma soepel kan overschakelen, moet nog bij de ontwikkelaar worden nagevraagd.

Bewaar vóór wijziging een herkenbare oude configuratie

Noteer de EA-naam, programmaversie, accounttype, server, instrument en grafiekperiode, en sla vervolgens de huidige invoerparameters op. De EA-invoerinstellingen van MT4 bieden laad- en opslagfuncties, maar een parameterbestand is geen back-up van de hele runtime-omgeving en kan programmabestanden, ordergegevens of runtimelogs niet vervangen.

De bestandsnaam kan datum, programmaversie en doel bevatten, bijvoorbeeld "simulatieverificatie" of "klaar voor livegang". Zet geen wachtwoorden in bestandsnamen of openbare registraties. Bewaar een vergelijking vóór en na de wijziging, zodat u niet uiteindelijk alleen een "nieuwste parameters" overhoudt waarvan het doel niet meer te bepalen is.

Vergelijk de betekenis van parameters, niet alleen de cijfers

Na een programma-upgrade kunnen de betekenis, standaardwaarde of eenheid van parameters met dezelfde naam veranderen. Controleer de documentatie van de ontwikkelaar en vergelijk vervolgens item voor item de daadwerkelijk aanwezige instellingen, zoals lotmethode, handelsuren, orderherkenning en exitvoorwaarden. Verzin geen parameters die niet bestaan.

Het wijzigen van invoerparameters activeert een herinitialisatie van de EA. Hoe het programma de status herstelt en met bestaande posities omgaat, hangt van de implementatie af. Controleer daarom eerst in een simulatieomgeving de initialisatielogboeken en orderherkenning, en beschouw "succesvol geladen" niet als bewijs dat alle gedragingen aan de verwachting voldoen.

Onderscheid gewone cloud-pc's van ingebouwde virtuele hosting

Een gewone cloudserver die u via remote desktop benadert, en de ingebouwde MetaTrader virtuele hosting van MT4 zijn twee verschillende omgevingen. Bij de eerste moet u in de externe terminal daadwerkelijk bestanden, grafieken en parameters controleren; dat u het op de lokale computer hebt gewijzigd, betekent niet dat een andere computer al is bijgewerkt.

Ingebouwde virtuele hosting migreert de omgeving via synchronisatie. De officiële uitleg is dat de synchronisatierichting van lokaal naar virtueel gaat en dat relevante programma's en externe parameters kunnen worden gemigreerd. Controleer vóór de handeling het gekozen migratietype en controleer na de handeling de externe logs, niet alleen de lokale grafiek.

Controleer vóór synchronisatie programma-afhankelijkheden en handelsautorisatie

Voor ingebouwde virtuele hosting is DLL-aanroepen officieel expliciet verboden, en scripts worden niet mee gemigreerd. Workflows die van dergelijke functies afhankelijk zijn, moeten eerst op compatibiliteit worden gecontroleerd. Negeer geen kritieke afhankelijkheidsfouten alleen om het programma "normaal te laten lijken".

Let ook goed op: de ingebouwde virtuele omgeving staat geautomatiseerde handel toe; dat lokaal geautomatiseerde handel verboden is, betekent niet dat het gemigreerde programma geen handel mag uitvoeren. Migreer alleen programma's waarvan u het doel begrijpt en hebt bevestigd. Deze regels zijn niet zonder meer van toepassing op alle externe cloudservers.

Controleer na synchronisatie de daadwerkelijk draaiende omgeving

Controleer de synchronisatietijd, initialisatie- en uitzonderingsinformatie in de externe logs, en de versie- of configuratie-identificatie die het programma kan leveren. Als de logs niet de volledige parameters tonen, gebruik dan de controlemethode van de ontwikkelaar en gis geen ontbrekende velden.

Het is raadzaam een updateregistratie bij te houden: reden van wijziging, oude en nieuwe waarden, resultaat van simulatieverificatie, synchronisatietijd en resultaat van externe controle. Vergelijk bij het observeren van orders de orderherkenningsregels van het account en het programma, om te voorkomen dat handmatige orders of de acties van een andere instantie door elkaar worden gehaald.

Lokaal stoppen betekent niet dat extern stopt

Bij het migreren van een EA via ingebouwde hosting wordt lokale geautomatiseerde handel automatisch uitgeschakeld om het risico van dubbel draaien op hetzelfde account te beperken. Dit betekent niet dat extern al is gestopt. Controleer tijdens onderhoud welke instantie daadwerkelijk draait en verifieer de externe status via de betreffende hostingbediening.

Het stoppen van een programma betekent ook niet dat posities zijn gesloten of openstaande orders zijn geannuleerd. In het onderhoudsplan moet de afhandeling van bestaande orders apart worden vastgelegd; het sluiten van een venster mag niet worden gezien als het einde van het risico.

Ook het terugzetten van oude parameters moet opnieuw worden geverifieerd

Laad bij het terugdraaien een oudere configuratie die u kunt bevestigen, controleer of de programmaversie compatibel is en verifieer vervolgens de huidige orderstatus en het resultaat van externe synchronisatie. De markt en accountstatus zijn al veranderd; het terugzetten van een bestand herstelt niet de vroegere handelsomgeving en garandeert niet dat oude parameters nog geldig zijn.

Handel met hefboomwerking kan tot aanzienlijke verliezen leiden. Dit artikel is bedoeld voor kennisdeling over operationeel onderhoud, vormt geen handelsinstructie en garandeert geen EA-prestaties of rendement.