Why Does Redundancy Redirect Use Port 0 After Failover?

After a redundancy failover, the browser is redirected from a working server on TCP port 80 to the peer server on port 0. The peer may be healthy and directly reachable, but the malformed redirect prevents the client from following it. Builds b2019021902 and b2019030902 showed this behavior. The correction was delivered in the build uploaded on 3/15; its build identifier was not stated.

Commissioning prerequisites

Before anything else, confirm that the fault belongs to redirect generation rather than server availability. A redundant application has two separate paths to test: direct access to each server and the redirect produced during failover. Testing only the redirected path can make a healthy backup look unavailable.

1. Record the installed build on both servers. Treat b2019021902 and b2019030902 as affected builds for this symptom.
2. Record the configured listening port for each server. The reported configuration used port 80 on both nodes.
3. Record each server's direct URL before initiating a failover.
4. Confirm that the redundancy state identifies one server as active and the other as its available peer.

Do not move on until both build values, both direct URLs, and the pre-failover redundancy state have been recorded.

Direct endpoint checks

Open each server directly, using its own host address and the configured listener. For this installation, test each node on port 80. A URL may omit an explicit :80 when the client uses ordinary HTTP, so the absence of a displayed port is not itself a failure. An explicit :0, however, selects port zero and is not equivalent to port 80.

1. Connect directly to the current active server and confirm that the application responds.
2. Connect directly to the backup server without relying on a redirect and confirm that it responds on port 80.
3. Repeat the checks from the same client that will be used for the failover test. This separates a client-to-server path problem from a server-generated redirect problem.
4. If either direct connection fails, correct that listener, name-resolution, routing, or filtering fault before testing redundancy.

A successful direct connection to both servers proves that port 80 is usable at each endpoint. Do not move on until both nodes answer directly from the test client.

Redirect capture and fault isolation

During failover, the active server returns an HTTP redirect containing a destination in the Location response header. The client follows that value; it does not independently substitute the backup server's configured listener. If the application constructs a destination containing :0, the browser displays or attempts that address even though the backup is listening correctly on port 80.

1. Start an HTTP capture with browser network diagnostics or another client that exposes response headers.
2. Connect through the normal active-server URL.
3. Trigger the supported failover operation.
4. Inspect the redirect response and record its Location value before any manual URL correction.
5. Compare the redirect host and port with the backup server's known direct URL.

The decisive result for this defect is a working direct backup URL paired with a captured redirect that explicitly contains port 0. Do not move on until the actual redirect value has been captured.

Corrected-build installation

No additional port configuration was identified as the correction for the reported case. The defect remained in b2019030902 and was fixed in the build uploaded on 3/15. Because the corrective build number was not supplied, identify it by its release date and release record rather than guessing an identifier.

1. Obtain the corrective build uploaded on 3/15 through the manufacturer's official software distribution or support channel.
2. Confirm that the package explicitly supersedes the affected build used on each server.
3. Preserve the current redundancy and listener configuration before applying the update.
4. Upgrade both redundancy partners according to the manufacturer's supported redundancy procedure. Avoid leaving the pair on different builds after commissioning.
5. Restart or reactivate components only as required by that installation procedure.
6. Read the running build from both nodes after installation; checking the downloaded filename alone does not prove which code is active.

Do not configure a listener on port 0 and do not rewrite the client URL as the permanent remedy. Do not move on until both nodes report the intended corrected build and remain visible as a redundancy pair.

Bidirectional failover verification

A one-way test can miss node-specific configuration or an incomplete update. Verify both directions because each server must generate a valid redirect when it is the active node.

1. Connect to server A while it is active and capture the current URL.
2. Fail over to server B. Confirm that the redirected destination identifies server B and either uses port 80 explicitly or applies the normal HTTP default without inserting :0.
3. Confirm that the application becomes usable without manually editing the address.
4. Restore or reverse the active role so server B redirects to server A.
5. Confirm the same host-and-port behavior in the reverse direction.
6. Repeat the test in a fresh client session to exclude a cached redirect from the result.

Do not move on until both A-to-B and B-to-A transitions complete without any URL containing :0.

Recurring commissioning pitfalls

The commissioning record should contain both running builds, both direct URLs, captured redirects in both directions, and confirmation that no transition produces port 0.

FAQ