diff --git a/changes/bug23347 b/changes/bug23347
new file mode 100644
index 0000000000..b0883784d2
--- /dev/null
+++ b/changes/bug23347
@@ -0,0 +1,6 @@
+  o Minor bug fixes (bridge client bootstrap):
+    - Make bridge clients download bridge descriptors immediately.
+      The bridge schedules were never correct, but we didn't realise until
+      the fix for 17750 made bridge clients hang for 15 minutes before
+      bootstrapping.
+      Fixes bug 23347. Not in any released version of Tor.
diff --git a/doc/tor.1.txt b/doc/tor.1.txt
index 9949f9dd0e..e3939d115a 100644
--- a/doc/tor.1.txt
+++ b/doc/tor.1.txt
@@ -2475,7 +2475,7 @@ The following options are used for running a testing Tor network.
        TestingClientDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
        TestingServerConsensusDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
        TestingClientConsensusDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
-       TestingBridgeDownloadSchedule 60, 30, 30, 60
+       TestingBridgeDownloadSchedule 0, 5, 10, 30, 60
        TestingClientMaxIntervalWithoutRequest 5 seconds
        TestingDirConnectionMaxStall 30 seconds
        TestingConsensusMaxDownloadTries 80
@@ -2541,7 +2541,8 @@ The following options are used for running a testing Tor network.
 
 [[TestingBridgeDownloadSchedule]] **TestingBridgeDownloadSchedule** __N__,__N__,__...__::
     Schedule for when clients should download bridge descriptors. Changing this
-    requires that **TestingTorNetwork** is set. (Default: 1200, 900, 900, 3600)
+    requires that **TestingTorNetwork** is set. (Default: 0, 8, 3600, 10800,
+    25200, 54000, 111600, 262800)
 
 [[TestingClientMaxIntervalWithoutRequest]] **TestingClientMaxIntervalWithoutRequest** __N__ **seconds**|**minutes**::
     When directory clients have only a few descriptors to request, they batch
diff --git a/src/or/bridges.c b/src/or/bridges.c
index 0818fb0812..f2244004f3 100644
--- a/src/or/bridges.c
+++ b/src/or/bridges.c
@@ -632,7 +632,9 @@ fetch_bridge_descriptors(const or_options_t *options, time_t now)
         continue;
       }
 
-      /* schedule another fetch as if this one will fail, in case it does */
+      /* schedule another fetch as if this one will fail, in case it does
+       * (we can't increment after a failure, because sometimes we use the
+       * bridge authority, and sometimes we use the bridge direct) */
       download_status_failed(&bridge->fetch_status, 0);
 
       can_use_bridge_authority = !tor_digest_is_zero(bridge->identity) &&
@@ -787,8 +789,13 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache)
     if (bridge) { /* if we actually want to use this one */
       node_t *node;
       /* it's here; schedule its re-fetch for a long time from now. */
-      if (!from_cache)
+      if (!from_cache) {
         download_status_reset(&bridge->fetch_status);
+        /* We have two quick attempts in the bridge schedule, and then slow
+         * ones */
+        download_status_failed(&bridge->fetch_status, 0);
+        download_status_failed(&bridge->fetch_status, 0);
+      }
 
       node = node_get_mutable_by_id(ri->cache_info.identity_digest);
       tor_assert(node);
diff --git a/src/or/config.c b/src/or/config.c
index 30853724e4..54df6c3e58 100644
--- a/src/or/config.c
+++ b/src/or/config.c
@@ -586,7 +586,10 @@ static config_var_t option_vars_[] = {
    * blackholed. Clients will try 3 directories simultaneously.
    * (Relays never use simultaneous connections.) */
   V(ClientBootstrapConsensusMaxInProgressTries, UINT, "3"),
-  V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "1200, 900, 900, 3600"),
+  /* The bridge code relies on the third item in this schedule being slow
+   * (~ 1 consensus interval) */
+  V(TestingBridgeDownloadSchedule, CSV_INTERVAL,
+    "0, 8, 3600, 10800, 25200, 54000, 111600, 262800"),
   V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "10 minutes"),
   V(TestingDirConnectionMaxStall, INTERVAL, "5 minutes"),
   V(TestingConsensusMaxDownloadTries, UINT, "8"),
@@ -648,7 +651,9 @@ static const config_var_t testing_tor_network_defaults[] = {
                                  "15, 20, 30, 60"),
   V(TestingClientConsensusDownloadSchedule, CSV_INTERVAL, "0, 0, 5, 10, "
                                  "15, 20, 30, 60"),
-  V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "60, 30, 30, 60"),
+  /* The bridge code relies on the third item in this schedule being slow
+   * (~ 1 consensus interval) */
+  V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "0, 5, 10, 30, 60"),
   V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "5 seconds"),
   V(TestingDirConnectionMaxStall, INTERVAL, "30 seconds"),
   V(TestingConsensusMaxDownloadTries, UINT, "80"),
diff --git a/src/or/directory.c b/src/or/directory.c
index 57dfdd9cac..6b5e16bfd4 100644
--- a/src/or/directory.c
+++ b/src/or/directory.c
@@ -5663,8 +5663,8 @@ download_status_get_initial_delay_from_now(const download_status_t *dls)
  * (We find the zeroth element of the download schedule, and set
  * next_attempt_at to be the appropriate offset from 'now'. In most
  * cases this means setting it to 'now', so the item will be immediately
- * downloadable; in the case of bridge descriptors, the zeroth element
- * is an hour from now.) */
+ * downloadable; when using authorities with fallbacks, there is a few seconds'
+ * delay.) */
 void
 download_status_reset(download_status_t *dls)
 {