fixed links

content/concepts/complex-payment-types/escrow.md

@@ -43,7 +43,7 @@ Escrow provides strong guarantees that are best suited for high-value, low-quant
 
 Conditional payments have been enabled by the ["Escrow" Amendment](known-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016.
 
-When testing in [stand-alone mode](stand-alone-mode.html), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
+When testing in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
 
     [features]
     Escrow

content/concepts/consensus-network/amendments.md

@@ -10,7 +10,7 @@ For a complete list of known amendments, their statuses, and IDs, see: [Known Am
 
 ## Background
 
-Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some _validators_ (`rippled` servers [participating in consensus](the-rippled-server.html#reasons-to-run-a-validator)) have upgraded to a new version of the software while other validators use the old version, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process][] might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
+Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some _validators_ (`rippled` servers [participating in consensus](rippled-server-modes.html#reasons-to-run-a-validator)) have upgraded to a new version of the software while other validators use the old version, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process][] might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
 
 Amendments solve this problem, so that new features can be enabled only when enough validators support those features.
 
@@ -221,7 +221,7 @@ To look up which `rippled` version supports these features, see [Known Amendment
 
 If you want to see how `rippled` behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use `rippled`'s configuration file to forcibly enable a feature. This is intended for development purposes only.
 
-Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](stand-alone-mode.html).
+Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode).
 
 To forcibly enable a feature, add a `[features]` stanza to your `rippled.cfg` file. In this stanza, add the short names of the features to enable, one per line. For example:
 

content/concepts/payment-system-basics/transaction-basics/transaction-basics.md

@@ -49,7 +49,7 @@ Sending a transaction to the XRP Ledger involves several steps:
 3. Submit a transaction to a `rippled` server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
 4. The [consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) determines which provisional transactions get included in the next validated ledger.
 5. The `rippled` servers apply those transactions to the previous ledger in a canonical order and share their results.
-6. If enough [trusted validators](the-rippled-server.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
+6. If enough [trusted validators](rippled-server-modes.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
 
 
 ### Example Unsigned Transaction

content/concepts/the-rippled-server/clustering.md

@@ -1,6 +1,6 @@
 # Clustering
 
-If you are running multiple [`rippled` servers](the-rippled-server.html) in a single datacenter, you can configure those servers into a cluster to maximize efficiency. Running your `rippled` servers in a cluster provides the following benefits:
+If you are running multiple `rippled` servers in a single datacenter, you can configure those servers into a cluster to maximize efficiency. Running your `rippled` servers in a cluster provides the following benefits:
 
 - Clustered `rippled` servers share the work of cryptography. If one server has verified the authenticity of a message, the other servers in the cluster trust it and do not re-verify.
 - Clustered servers share information about peers and API clients that are misbehaving or abusing the network. This makes it harder to attack all servers of the cluster at once.

content/concepts/the-rippled-server/peer-protocol.md

@@ -160,7 +160,7 @@ Response:
 
 You can use the `[peer_private]` stanza of the `rippled` config file to request that peer servers do not report your IP address in the Peer Crawler response. Servers you do not control can be modified not to respect this setting. However, you can use this to hide the IP addresses of `rippled` servers you control that _only_ connect to peers you control (using `[ips_fixed]` and a firewall). In this way, you can use public rippled servers you control as proxies for your private rippled servers.
 
-To protect an important [validating server](the-rippled-server.html#types-of-rippled-servers), Ripple recommends configuring one or more public tracking servers to act as proxies, while the validating server is protected by a firewall and only connects to the public tracking servers.
+To protect an important [validating server](rippled-server-modes.html#types-of-rippled-servers), Ripple recommends configuring one or more public tracking servers to act as proxies, while the validating server is protected by a firewall and only connects to the public tracking servers.
 
 <!--{# TODO: network diagram of private peers #}-->
 

content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.md

@@ -1,7 +1,7 @@
 # validation_create
 [[Source]<br>](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/ValidationCreate.cpp "Source")
 
-Use the `validation_create` command to generate the keys for a rippled [validator](the-rippled-server.html#reasons-to-run-a-validator). Similar to the [wallet_propose method][], this command makes no real changes, but only generates a set of keys in the proper format.
+Use the `validation_create` command to generate the keys for a rippled [validator](rippled-server-modes.html#reasons-to-run-a-validator). Similar to the [wallet_propose method][], this command makes no real changes, but only generates a set of keys in the proper format.
 
 _The `validation_create` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
 

content/tutorials/manage-account-settings/set-up-multi-signing.md

@@ -18,7 +18,7 @@ This tutorial demonstrates how to enable multi-signing for an address.
 
 You need an XRP Ledger address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the [account reserve](reserves.html) and [transaction cost](transaction-cost.html), increasing with the number of signers and signatures you use.
 
-If you started `rippled` in [stand-alone mode](stand-alone-mode.html) with a new genesis ledger, you must:
+If you started `rippled` in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode) with a new genesis ledger, you must:
 
 1. Generate keys for a new address, or reuse keys you already have.
 2. Submit a Payment transaction to fund the new address from the genesis account. (Send at least 100,000,000 [drops of XRP][].)

content/tutorials/manage-the-rippled-server/run-rippled-as-a-validator.md

@@ -6,7 +6,7 @@ Running a `rippled` validator that participates in the Consensus process is simp
     * At first, your server is an _untrusted validator_. Others can see the validations your server issues, but they disregard them in the consensus process.
 2. Share the public key with the public, especially other `rippled` operators.
 3. When other `rippled` operators add your public key to their list of trusted servers, you have become a _trusted validator_.
-    * Also see [Properties of a Good Validator](the-rippled-server.html#properties-of-a-good-validator) for best practices.
+    * Also see [Properties of a Good Validator](rippled-server-modes.html#properties-of-a-good-validator) for best practices.
 
 
 ## Validator Setup

content/use-cases/run-a-rippled-validator.md

@@ -8,7 +8,7 @@ Each `rippled` server (not running in stand-alone mode) connects to a network of
 
 <span class="use-case-step-num">{{n.next()}}</span>
 <!-- <span class="use-case-step-length">(1 hour)</span> -->
-## [Understand what it means to run a validator](the-rippled-server.html#reasons-to-run-a-validator)
+## [Understand what it means to run a validator](rippled-server-modes.html#reasons-to-run-a-validator)
 
 If you or your organization relies on the XRP Ledger, it is in your interest to run a validator to participate in the consensus process and provide a trusted validator that supports the ongoing decentralization of the XRP Ledger.