Replace host in Uri
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
If you need to send the same request to another server, changing only the host is a common task. In .NET, the safe way to do that is to parse the address as a Uri and rebuild it with UriBuilder, instead of trying to patch the string by hand.
Why String Replacement Fails
A URI is not just a hostname followed by a path. It can include a scheme, port, username, password, query string, and fragment. A plain text replacement often works for the happy path, then breaks as soon as one of those extra parts appears.
For example, this approach is fragile:
The code above changes the visible host, but it assumes the old host appears exactly once and only inside the authority section. If the same text appears in the query string or path, you can silently corrupt the URI.
Another problem is encoding. A URI may contain escaped characters in the path or query. Treating the entire address as raw text makes it easy to produce a value that looks correct but no longer parses the same way.
Use UriBuilder to Replace the Host
UriBuilder exists for this exact job. It lets you parse the original Uri, change one component, and keep everything else intact.
That produces a new URI with the new host while preserving the scheme, port, path, query string, and fragment. This is usually what you want when moving traffic between environments such as staging, production, or an internal proxy.
If you also need to swap the scheme or port, change those explicitly:
Setting each field directly makes the intent obvious and avoids hidden assumptions.
Encapsulate the Logic in a Helper
If the same transformation happens in several places, wrap it in a helper method. That keeps URI parsing rules in one place and makes the call site easier to read.
This pattern also gives you a clean place to validate input. For example, you may want to reject an empty host name or enforce HTTPS when switching to a public endpoint.
Relative URIs Need Different Handling
UriBuilder only works with absolute URIs. If you are dealing with a relative path such as /api/orders?page=2, there is no host to replace yet. In that case, combine the relative URI with a base address first.
Once you have an absolute URI, you can use the same UriBuilder pattern shown earlier.
Common Pitfalls
Replacing the host with string.Replace is the most common mistake. It looks shorter, but it ignores URI structure and can modify the wrong part of the address.
Forgetting the port is another frequent issue. If the old URI uses a non-default port, that port will stay in place unless you change it. Moving from http on 8080 to https on 443 often requires updating both fields.
Relative URIs also trip people up. A path by itself does not have a host, so there is nothing to replace until you resolve it against a base URI.
Finally, watch for user info in legacy addresses. If the original URI contains embedded credentials, UriBuilder preserves them. That may be correct for an internal migration, but it may also copy secrets into a context where they no longer belong.
Summary
- Use
UriandUriBuilderinstead of raw string replacement. - Changing the host does not automatically change the scheme or port.
- Wrap repeated URI transformations in a helper method.
- Resolve relative paths against a base URI before trying to modify the host.
- Preserve intent explicitly so the rewritten URI is predictable and safe.

