Match this symptom
The launch command appears to request a custom gameplay port, but socket inspection and connection attempts still point to UDP 7777.
The answer first
Back up the launch configuration and stop the server, replace ASE-style ?Port=<value> with ASA's -port=<value>, reserve value+1 for companion traffic, and keep QueryPort as its own UDP value. Update only those three rules and verify the actual sockets before testing from outside.

Freeze the instance before changing network identity
Changing ports while clients, firewall rules or a second map still expect the old set creates overlapping failures. Save the map, run DoExit, confirm the process has stopped, and copy the launch configuration and both INIs before editing.
Record every local ASA instance. Each concurrent map needs a unique, non-overlapping gameplay pair and query port; a collision can make a valid command appear broken.
- 1Run cheat SaveWorld and wait for completion.
- 2Run DoExit and verify ArkAscendedServer.exe is gone.
- 3List the game, game+1, query and optional RCON values for every instance.
Use ASA's hyphen argument for gameplay
The official-community setup reference states that ASA changes its game port with -port=<value>, unlike ASE's older ?Port= form. Hyphen arguments are separated by spaces after the map/question-mark block.
Do not change every port at once. Choose one unused base, set -port to it and reserve the next UDP value. Leave RCON disabled during the player-connectivity test because it is unrelated to gameplay.
- Gameplay: UDP <base> selected by -port=<base>
- Companion/peer: UDP <base+1>
- Query/browser: UDP value selected separately, default 27015
Verify listeners before touching the router
Start the server privately and inspect the process command line and bound UDP sockets. If it still owns 7777, confirm the service is launching the edited script and that no stale ASA process is using the desired port.
A browser listing confirms query registration only. It does not prove the gameplay pair is reachable, and an RCON response proves neither player path.
- 1Wait until the selected map has completed startup.
- 2Confirm the expected base, base+1 and query sockets belong to this process.
- 3Correct the service's executable/argument source if the running command differs from the edited file.
Change the narrow firewall and router set
Update the Windows Firewall rules owned by this instance and, for direct public hosting, forward the new UDP game pair and query value to the host's reserved LAN address. Remove the superseded rules after the new path passes so documentation does not accumulate misleading openings.
Test from a genuinely external network with a build-matched client. A LAN success does not validate NAT, and a phone connected to home Wi-Fi is still a LAN test.
- Verify Windows Firewall ownership and profile.
- Verify router target LAN address and avoid double NAT/CGNAT assumptions.
- Record browser visibility and actual map entry as separate results.
