Deployed 83514d1 with MkDocs version: 1.6.1

guide/proxies-and-vpn/index.html

@@ -3339,8 +3339,7 @@ machine (a <code>remote_services</code> URL on <code>127.0.0.1</code>) can reach
 <div class="admonition warning">
 <p class="admonition-title">Docker is required</p>
 <p>Gluetun needs a working <a href="https://docs.docker.com/get-docker/">Docker</a> installation on
-your <code>PATH</code>. If Docker is not found, the proxy provider fails to load with an error linking
-to the install docs. The container also needs the <code>NET_ADMIN</code> capability and access
+your <code>PATH</code>. If Docker is not found, the proxy provider fails to load. The container also needs the <code>NET_ADMIN</code> capability and access
 to <code>/dev/net/tun</code> to bring up the tunnel. unshackle requests both automatically.</p>
 </div>
 <h3 id="query-format">Query format<a class="headerlink" href="#query-format" title="Permanent link">&para;</a></h3>
@@ -3434,7 +3433,8 @@ credentials, and how your region aliases map onto Gluetun's server selectors.</p
 <li><code>private_key</code> is <strong>always</strong> required.</li>
 <li><code>surfshark</code>, <code>mullvad</code>, and <code>ivpn</code> also require <code>addresses</code>.</li>
 <li><code>windscribe</code> additionally requires <strong>both</strong> <code>addresses</code> and <code>preshared_key</code>
-  (<code>preshared_key</code> may be an empty string, but the config key must be present).</li>
+  (<code>preshared_key</code> may be an empty string, but the config key must be present).
+  Get both from the <a href="https://windscribe.com/getconfig/wireguard">Windscribe WireGuard config generator</a>.</li>
 <li>NordVPN and Proton VPN need only <code>private_key</code>.</li>
 </ul>
 </div>

guide/troubleshooting/index.html

@@ -2605,6 +2605,11 @@
 <p><strong>Inspect:</strong> set <code>debug_requests: true</code> and operate unshackle with <code>-d</code> to show the underlying <code>urllib3</code> / <code>rnet</code> / <code>httpx</code> logs. In the JSON debug log, filter for <code>service_call</code> operations to see which request failed. If you use a proxy, also read <a href="../proxies-and-vpn/">Proxies &amp; VPN</a>.</p>
 </div>
 <div class="admonition example">
+<p class="admonition-title">A segment download fails after every retry</p>
+<p><strong>Symptom:</strong> the download stops with a line like <code>MaxRetriesError: GET &lt;host&gt; failed: RequestError (stream closed because of a broken pipe), gave up after 5 failed attempts over 30s</code>.</p>
+<p><strong>Inspect:</strong> the connection to the CDN host dropped on every attempt. This is almost always the network, the VPN, or the proxy, not the service. Run the download again: unshackle keeps the segments it already has. Over HTTP/2, all segments share one connection, so one drop fails every segment in flight. Set <code>network.http1_only: true</code> (see <a href="../../reference/configuration/network/">Network &amp; proxy</a>) to spread them over separate connections. Operate unshackle with <code>-d</code> to see each retry as a <code>segment_retry</code> entry in the JSON debug log.</p>
+</div>
+<div class="admonition example">
 <p class="admonition-title">The wrong titles/metadata keep coming back</p>
 <p><strong>Symptom:</strong> a service returns outdated titles even after the source changed.</p>
 <p><strong>Inspect:</strong> the title cache is likely serving stale data. Clear it with <code>unshackle env clear cache &lt;SERVICE&gt;</code>, or bypass it for one run using the <code>dl</code> no-cache / reset-cache options (see <a href="../downloading/">Downloading</a> and the <a href="../cli-reference/#dl">CLI Reference</a>).</p>