diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 660fc904fc2aecf00ff602a88c8018ec85b3a1ba..eb8fb1ee26ce25ba3f9e14911b221f23d5f5946a 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -622,7 +622,7 @@ This happens on wrongly-formatted addresses in `postgresql['md5_auth_cidr_addres
```
To fix this, update the IP addresses in `/etc/gitlab/gitlab.rb` under `postgresql['md5_auth_cidr_addresses']`
-to respect the CIDR format (that is, `1.2.3.4/32`).
+to respect the CIDR format (for example, `10.0.0.1/32`).
### Message: `LOG: invalid IP mask "md5": Name or service not known`
@@ -634,7 +634,7 @@ This happens when you have added IP addresses without a subnet mask in `postgres
```
To fix this, add the subnet mask in `/etc/gitlab/gitlab.rb` under `postgresql['md5_auth_cidr_addresses']`
-to respect the CIDR format (that is, `1.2.3.4/32`).
+to respect the CIDR format (for example, `10.0.0.1/32`).
### Message: `Found data in the gitlabhq_production database!` when running `gitlab-ctl replicate-geo-database`
@@ -1295,7 +1295,7 @@ When [Geo proxying for secondary sites](../secondary_proxy/index.md) is enabled,
Check the NGINX logs for errors similar to this example:
```plaintext
-2022/01/26 00:02:13 [error] 26641#0: *829148 upstream sent too big header while reading response header from upstream, client: 1.2.3.4, server: geo.staging.gitlab.com, request: "POST /users/sign_in HTTP/2.0", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket:/users/sign_in", host: "geo.staging.gitlab.com", referrer: "https://geo.staging.gitlab.com/users/sign_in"
+2022/01/26 00:02:13 [error] 26641#0: *829148 upstream sent too big header while reading response header from upstream, client: 10.0.2.2, server: geo.staging.gitlab.com, request: "POST /users/sign_in HTTP/2.0", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket:/users/sign_in", host: "geo.staging.gitlab.com", referrer: "https://geo.staging.gitlab.com/users/sign_in"
```
To resolve this issue:
@@ -1345,15 +1345,8 @@ To fix this issue, set the primary site's internal URL to a URL that is:
- Unique to the primary site.
- Accessible from all secondary sites.
-1. Enter the [Rails console](../../operations/rails_console.md) on the primary site.
-
-1. Run the following, replacing `https://unique.url.for.primary.site` with your specific internal URL.
- For example, depending on your network configuration, you could use an IP address, like
- `http://1.2.3.4`.
-
- ```ruby
- GeoNode.where(primary: true).first.update!(internal_url: "https://unique.url.for.primary.site")
- ```
+1. Visit the primary site.
+1. [Set up the internal URLs](../../../user/admin_area/geo_sites.md#set-up-the-internal-urls).
### Secondary site returns `Received HTTP code 403 from proxy after CONNECT`
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index f80a5192c55f818c927520bca609c20b58c979cc..a93f4aea5dc519b5436688233f79ae95a5ddd950 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -1107,8 +1107,8 @@ For more information on Gitaly server configuration, see our
```ruby
# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your front door GitLab URL or an internal load balancer.
- # Examples: 'https://gitlab.example.com', 'http://1.2.3.4'
- gitlab_rails['internal_api_url'] = 'http://GITLAB_HOST'
+ # Examples: 'https://gitlab.example.com', 'http://10.0.2.2'
+ gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
```
1. Configure the storage location for Git data by setting `gitaly['configuration'][:storage]` in
diff --git a/doc/ci/ssh_keys/index.md b/doc/ci/ssh_keys/index.md
index 09a85168f9b7833fa7f2f3d83a0914857b4f8123..15b731f88c87a5dbe98bff79618aeaa6d458f0f4 100644
--- a/doc/ci/ssh_keys/index.md
+++ b/doc/ci/ssh_keys/index.md
@@ -156,7 +156,7 @@ trusted network (ideally, from the private server itself):
ssh-keyscan example.com
## Or use an IP
-ssh-keyscan 1.2.3.4
+ssh-keyscan 10.0.2.2
```
Create a new [file type CI/CD variable](../variables/index.md#use-file-type-cicd-variables)
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index 62441f6de8f09b160ac177b59cd6ce4a89c8b54b..f3ea7829ace1813034dae22fe75dabfec6db54b6 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -442,7 +442,7 @@ above error message.
To fix this, ensure that the forward and reverse DNS for your GitLab server
match. So for instance, if you access GitLab as `gitlab.example.com`, resolving
-to IP address `1.2.3.4`, then `4.3.2.1.in-addr.arpa` must be a `PTR` record for
+to IP address `10.0.2.2`, then `2.2.0.10.in-addr.arpa` must be a `PTR` record for
`gitlab.example.com`.
#### Missing Kerberos libraries on browser or client machine
diff --git a/doc/topics/autodevops/prepare_deployment.md b/doc/topics/autodevops/prepare_deployment.md
index b71beee708e2fc7f550d2cdeaffacccf2c31e460..e69c0ca09097ea5d7eea2f59cabfd11efe58ec35 100644
--- a/doc/topics/autodevops/prepare_deployment.md
+++ b/doc/topics/autodevops/prepare_deployment.md
@@ -54,17 +54,17 @@ Auto DevOps requires a wildcard DNS `A` record matching the base domains. For
a base domain of `example.com`, you'd need a DNS entry like:
```plaintext
-*.example.com 3600 A 1.2.3.4
+*.example.com 3600 A 10.0.2.2
```
-In this case, the deployed applications are served from `example.com`, and `1.2.3.4`
+In this case, the deployed applications are served from `example.com`, and `10.0.2.2`
is the IP address of your load balancer, generally NGINX ([see requirements](requirements.md)).
Setting up the DNS record is beyond the scope of this document; check with your
DNS provider for information.
Alternatively, you can use free public services like [nip.io](https://nip.io)
which provide automatic wildcard DNS without any configuration. For [nip.io](https://nip.io),
-set the Auto DevOps base domain to `1.2.3.4.nip.io`.
+set the Auto DevOps base domain to `10.0.2.2.nip.io`.
After completing setup, all requests hit the load balancer, which routes requests
to the Kubernetes pods running your application.
diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md
index dd73a2056e54304686ec58490275f29cf569cbc7..bfb88cf0dc4c63394812a401a33d3923aee40c4a 100644
--- a/doc/topics/autodevops/requirements.md
+++ b/doc/topics/autodevops/requirements.md
@@ -71,17 +71,17 @@ Auto DevOps requires a wildcard DNS `A` record that matches the base domains. Fo
a base domain of `example.com`, you'd need a DNS entry like:
```plaintext
-*.example.com 3600 A 1.2.3.4
+*.example.com 3600 A 10.0.2.2
```
-In this case, the deployed applications are served from `example.com`, and `1.2.3.4`
+In this case, the deployed applications are served from `example.com`, and `10.0.2.2`
is the IP address of your load balancer, generally NGINX ([see requirements](requirements.md)).
Setting up the DNS record is beyond the scope of this document; check with your
DNS provider for information.
Alternatively, you can use free public services like [nip.io](https://nip.io)
which provide automatic wildcard DNS without any configuration. For [nip.io](https://nip.io),
-set the Auto DevOps base domain to `1.2.3.4.nip.io`.
+set the Auto DevOps base domain to `10.0.2.2.nip.io`.
After completing setup, all requests hit the load balancer, which routes requests
to the Kubernetes pods running your application.
diff --git a/doc/user/project/remote_development/connect_machine.md b/doc/user/project/remote_development/connect_machine.md
index f981918c0ea8a3d8b17d503ac3d5b49206e40c75..53c5d342f74fc8d89df6476d9793c97bd7c0e29e 100644
--- a/doc/user/project/remote_development/connect_machine.md
+++ b/doc/user/project/remote_development/connect_machine.md
@@ -26,7 +26,7 @@ To connect a remote machine to the Web IDE, you must:
To generate Let's Encrypt certificates:
-1. Create an `A` record to point a domain to your remote machine (for example, from `example.remote.gitlab.dev` to `1.2.3.4`).
+1. Create an `A` record to point a domain to your remote machine (for example, from `example.remote.gitlab.dev` to `10.0.2.2`).
1. Install [Certbot](https://certbot.eff.org/) to enable HTTPS:
```shell