Change a destination

Know what counts as a change

The destination is one IP address and UDP port pair. Changing either field is an address change. Every address change requires a new proof-of-control challenge at the new pair.

Each destination permits ${ADDRESS_CHANGES_PER_DAY} address changes per day. The time zone, reset boundary, remaining-change display, and behavior of a no-op save are not currently specified. Avoid unnecessary saves and use the dashboard's current result as the operational record.

The paid slot remains one destination. A change does not create documented parallel fanout to the old and new pairs.

Prepare the new path before saving

Build and test the customer-controlled path first. Every challenge and stream datagram comes from ${SOURCE_IP}. Add that source to the new firewall path before requesting verification.

1. Allocate the new public IP and UDP port.
2. Bind the new receiver to its local UDP port.
3. Add a static UDP mapping when NAT is present.
4. Allow ${SOURCE_IP}/32 at the new edge firewall.
5. Allow ${SOURCE_IP}/32 at the new host firewall.
6. Start a source-filtered packet capture at the new receiver.
7. Record the old destination pair and state.

Use a local test packet only to confirm the receiver binding and internal path. It cannot replace the provider challenge because proof requires receiving the service datagram from ${SOURCE_IP} at the configured public pair.

Save and verify the new pair

1. Open the existing destination in the dashboard.
2. Enter the new public IP address.
3. Enter the new UDP port.
4. Save the new pair.
5. Request the verification challenge.
6. Read the token from the datagram at the new receiver.
7. Paste the token into the dashboard.
8. Submit the token within ${CHALLENGE_TTL_SECONDS} seconds.
9. Keep the new receiver open.

The challenge begins with SHRED-FANOUT-VERIFY/1, followed by the destination ID and token. Its exact field delimiter is not currently specified. The service sends one datagram for a request. Request a resend when the packet is lost or the token expires.

Do not paste a token captured on the old receiver or from an earlier request. The new challenge proves control of the changed pair.

Confirm new delivery

Replace 9000 with the new destination port and run on the new host:

sudo tcpdump -n -i any -c 20 'src host 64.130.40.90 and udp dst port 9000'

Confirm that the application counter advances over the same interval. A capture proves that the host sees packets, while the application counter proves that the socket path accepts them.

The exact activation delay after re-verification is not currently specified. Record UTC times for token acceptance, first captured stream packet, and first application packet instead of assuming a threshold.

Retire the old customer path

Remove old firewall and NAT entries only after confirming the new path. Stop the old receiver according to the customer's change policy. These actions do not create or delete a destination in the provider account.

Provider-side parallel delivery, rollback to the prior pair without consuming another change, and a transactional cutover guarantee are not currently specified. Treat any return to the old pair as another address change that requires verification unless the dashboard states otherwise.

Keep the old configuration record with UTC timestamps long enough to investigate a cutover incident under your own retention policy. A required record-retention period is not currently specified.

Handle NAT port changes

The public destination port and internal receiver port can differ under NAT. Changing only the internal mapping while leaving the registered public pair unchanged is a customer network change, not necessarily a dashboard address change. It still can interrupt delivery.

When the public port changes, update the dashboard and complete verification. When only the internal port changes, update the NAT rule and host firewall together, then confirm capture and application counts. Whether the dashboard treats any specific edit as a counted change is authoritative in the interface.

Avoid consuming the change cap

Do not use destination edits to test whether a port is open. Bind the socket, inspect firewall policy, and validate internal routing before saving the new pair. Use one planned dashboard change for one prepared migration.

Do not alternate between old and new addresses while diagnosing. Each save can require another challenge and can consume the daily allowance. Preserve the last verified working pair when further changes are blocked.

If the dashboard reports the daily cap, wait until it permits another change. An override, increased limit, exact reset time, and support exception are not currently specified.

Plan a production migration

Choose a change window that permits observation of both network edges. Assign one operator to the dashboard and one to receiver telemetry when staffing allows. Record destination ID, old pair, new pair, requested challenge time, accepted token time, first packet time, and counter deltas.

This operating method is a customer recommendation. The product does not specify a maintenance-window scheduler, migration API, webhook, or status callback.

Account for raw UDP behavior during the cutover. There is no ordering, retransmission, or backpressure. Packets sent to a closed or blocked path cannot be requested again from the transport.

Diagnose a failed change

If no challenge reaches tcpdump, verify that the saved public pair is correct and every new layer allows ${SOURCE_IP}. If tcpdump sees the challenge but the receiver does not, inspect the bind address, local firewall, and network namespace.

If the dashboard rejects the token, request a fresh challenge and submit its current token within ${CHALLENGE_TTL_SECONDS} seconds. If verification succeeds but the stream is absent, compare the dashboard pair with the capture filter and receiver binding.