We do not choose any router in the same family as another in the same
path. (Two routers are in the same family if each one lists the other
in the "family" entries of its descriptor.)

We do not choose more than one router in a given /16 subnet
(unless EnforceDistinctSubnets is 0).

We don't choose any non-running or non-valid router unless we have
been configured to do so. By default, we are configured to allow
non-valid routers in "middle" and "rendezvous" positions.

If we're using Guard nodes, the first node must be a Guard (see 5
below)

For "fast" circuits, we only choose nodes with the Fast flag. For
non-"fast" circuits, all nodes are eligible.

For all circuits, we weight node selection according to router
bandwidth.

We also weight the bandwidth of Exit and Guard flagged nodes
depending on the fraction of total bandwidth that they make up and
depending upon the position they are being selected for.

...

Additionally, we may be building circuits with one or more requests
in mind. Each kind of request puts certain constraints on paths:

All service-side introduction circuits and all rendezvous paths
should be Stable.

All connection requests for connections that we think will need to
stay open a long time require Stable circuits. Currently, Tor decides
this by examining the request's target port, and comparing it to a
list of "long-lived" ports. (Default: 21, 22, 706, 1863, 5050,
5190, 5222, 5223, 6667, 6697, 8300.)

Reverse DNS resolves require a version of Tor with advertised eventdns
support (available in Tor 0.1.2.1-alpha-dev and later).

All connection requests require an exit node whose exit policy
supports their target address and port (if known), or which "might
support it" (if the address isn't known). See 2.2.1.

2.2.1. Choosing an exit

If we know what IP address we want to connect to or resolve, we can
trivially tell whether a given router will support it by simulating
its declared exit policy.

Because we often connect to addresses of the form hostname:port, we
do not always know the target IP address when we select an exit
node. In these cases, we need to pick an exit node that "might
support" connections to a given address port with an unknown
address. An exit node "might support" such a connection if any
clause that accepts any connections to that port precedes all
clauses (if any) that reject all connections to that port.

Unless requested to do so by the user, we never choose an exit node
flagged as "BadExit" by more than half of the authorities who
advertise themselves as listing bad exits.