Model Download Proxy Timeout Diagnosis

Direct answer

A proxy-related timeout is a symptom with several possible stages, not a diagnosis. Determine whether the request used a direct connection or a proxy, whether the connection phase completed, whether response headers arrived, and whether the body stopped after bytes began. Then inspect the response status, final URL, and partial-file identity before retrying. Do not treat “timed out” as proof that the model file is corrupt, and do not disable TLS certificate checks to make a proxy path appear to work. A timeout may result from network route, proxy reachability, DNS, TLS negotiation, server response, or a read stall; distinguish these with evidence rather than guessing from one exception label. The project downloader uses HttpURLConnection, sets connect and read timeout policies, requests identity encoding and a Range starting at the current temporary-file length, and may try a configured mirror for socket timeout or DNS failure. Other exceptions return an error. The code does not establish that a proxy caused any observed timeout, nor that a particular corporate or captive network is supported. The guide should use the repository’s real path as a trace example while presenting a diagnostic method, not calling any error string common or claiming a fix without a captured log or reproducible case. Android’s ProxySelector API describes how a URL connection can obtain direct or proxied routes and exposes a connect-failure callback for proxy selectors. HttpURLConnection exposes separate connect and read timeout settings; a read timeout can occur when no bytes arrive during a read. Android Studio Network Inspector can show supported HttpsURLConnection and OkHttp traffic, but its documentation explicitly limits which libraries it can inspect. Therefore, first confirm the exact client in the app; if traffic is not visible, absence from the inspector is not proof the app made no request. The current project uses HttpURLConnection, so use compatible tooling or controlled instrumentation. Record timing boundaries without user content: request start, proxy choice if observable, DNS/connection outcome, TLS outcome, header arrival, first byte, body progress, cancellation, and response close. Avoid sensitive query parameters and credentials in logs. Compare a known-good direct test route only when permitted by network policy; do not bypass an organization’s proxy or certificate policy. If using a staging server, exercise delayed connect, delayed headers, stalled body, HTTP failure, and clean range response independently so the failure stage is unambiguous. Retry policy is a separate decision. A transient timeout may allow a later attempt, but only after the transfer owner verifies whether partial bytes match the same artifact and whether the Range response can continue that representation. Do not append new data until response status and range metadata are validated. If no response headers arrived, the existing partial file may still be valid, but that depends on write and flush boundaries; reconcile it with the transfer manifest. If the response reached the body and then stalled, record actual bytes persisted. If proxy or TLS negotiation fails, changing source mirrors may not help and may violate policy; never retry indefinitely. Keep support outputs safe and actionable. Provide a diagnostic receipt with app build, Android version, network route category, client type, failure stage, HTTP status if available, artifact revision, and partial state. Omit prompts, transcripts, bearer tokens, cookies, full signed URLs, and raw model bytes. The user-facing message can say the configured route did not complete and offer to retry on a permitted network, wait, or cancel; it should not state that a proxy is broken unless evidence identifies it. If the app cannot observe the proxy choice, say route details are unknown. ### Procedure 1. Freeze the reproduction context: app build, Android version, download client, artifact revision, network policy, proxy configuration category, and whether a partial file existed. 2. Separate stages using the correct instrumentation. Record DNS/connect, proxy selection, TLS, response headers, first byte, and read stall; account for Network Inspector’s supported-client limits. 3. Inspect current response and partial state. Capture status/range metadata and file offset where available; do not append until the same representation is established. 4. Reproduce on a controlled endpoint with one delay or failure at a time. Keep direct-route comparisons within the permitted network policy and do not weaken TLS validation. 5. Choose recovery only after classifying the stage. Retry, wait, cancel, or escalate with privacy-safe diagnostics; prevent indefinite loops and preserve the active model. ### Acceptance criteria - Timeout reports distinguish connection, response-header, and body-read stages where observable; unknown route details remain unknown. - Proxy or certificate errors never trigger disabled TLS checks or unauthorized network bypass. - Existing partial bytes are reconciled to artifact identity and validated range metadata before resume. - Logs and support receipts exclude private content and credentials, and retry has a bounded, user-visible policy. ### Comparison | Observation | Supports | Does not prove | |---|---|---| | Connect timeout | The connection did not complete within the configured policy | Whether proxy, DNS, route, or origin alone caused it | | Read timeout after headers | Response began but a read did not receive data in time | That partial model bytes are corrupt | | Missing Network Inspector event | No supported request was captured by that tool | That no network request occurred | ### FAQ **Does a proxy timeout mean the model artifact is corrupt?** No. It describes a network-stage failure. First classify proxy selection, connection, response, and body-read states, then reconcile any partial bytes against the artifact identity. **Can I disable certificate validation to test a corporate proxy?** Do not do so in a production path. Follow the organization’s approved trust configuration and use a controlled test environment; a timeout or TLS failure is not permission to weaken validation. **Why does Network Inspector show no request?** The tool supports specific network clients, including HttpsURLConnection and OkHttp. Confirm which client the app uses; missing inspector data alone does not prove no request was made. **Should the app switch to a mirror after every proxy timeout?** Not automatically. A mirror may use the same blocked route or violate policy. Classify the stage, check whether partial bytes remain valid, and offer a bounded retry or permitted network change.

A model download stalls on a network with a configured proxy

A developer reproduces a transfer stall on one network route but not another. The app has a partial model file and reports a timeout category. The team needs to distinguish connection failure from a stalled response body without weakening TLS or guessing that data is corrupt.

Decision

Capture the route and timing stages with compatible instrumentation, validate partial response identity, and choose recovery only after classifying the timeout boundary.

Expected outcome

The record says what was observed, unknown route causes stay unknown, and the app offers bounded retry or user choice without unsafe network bypass.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Request and response timeline
• Partial-file identity
• Retry and final verification outcome

A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.

Implementation workflow

1. Record reproduction context. Capture app build, Android release, client library, artifact revision, network route category, proxy policy, and whether partial bytes existed; never include secrets or user prompts.
2. Instrument connection and read phases. Separate proxy selection, DNS/connect, TLS, response-header arrival, first byte, and later read stall using the client’s supported logs or a controlled endpoint.
3. Confirm the inspection tool covers the client. Check whether the app uses a supported connection library before interpreting missing network events. If visibility is incomplete, report route details as unknown.
4. Reconcile the partial artifact. Read persisted file offset and transfer metadata, verify response status and Range continuation where available, and do not append until the same representation is confirmed.
5. Apply bounded recovery. Retry only under policy after stage classification, or offer wait, cancel, or a permitted route. Preserve the working model and do not disable TLS or loop through mirrors indefinitely.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Logs and UI distinguish connect, header, and body-read stages when evidence exists.
• Unknown proxy causes remain unknown; no certificate-validation bypass or policy violation is suggested.
• Resume is allowed only after partial-file identity and response-range compatibility are checked.
• Diagnostics are redacted, retries are bounded, and the user has a visible recovery choice.

Decision table

Failure patterns to prevent

• Retrying forever
• Combining timeout with corruption

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android ProxySelector API
• Android URLConnection timeout API
• Android Studio Network Inspector supported clients

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions