WordPress video stalls during playback: check HTTP ranges

Find the address of the video actually played

A WordPress video is visible on the page. It may even start on a computer, then stall on mobile or when the visitor moves the playhead. On the WordPress forum, a member reported Web Stories videos working on desktop but not phones. The reply reproduced the problem at a direct MP4 address in Safari and identified missing support for byte-range requests. The thread reports no post-correction test. The useful check is to remove the player from the equation, then test file delivery.

An HTML video may request portions of a file. The beginning helps the browser recognize the resource, then seeking may require bytes elsewhere. The HTTP request then contains a Range header. The check below targets progressive video served as one file. An HLS or DASH player loads a manifest and segments, sometimes using ranges, and requires following the requests actually used. A block poster, subtitle track and video file each have their own address.

In the browser, open developer tools, choose Network and reload the page. Start playback, then seek one-third of the way through. Find the MP4 address or filename in the list. Follow the request to its final response after redirects. If rewritten to a CDN, retain that hostname in diagnosis. For a standard Video block, compare it with the file address under Media > Library. For an external embed, use the player's Network panel and provider tools when the stream is in a separate frame.

1. Record the video document URL, time and failing situation. State whether startup, seeking or both are affected. Hide signed parameters before sharing a trace.
2. Open a public media file's direct address in the affected browser and test the same seek. Compare with a control video known to work.
3. If the direct MP4 works but the page fails, check the source chosen by the block or player. If the direct address also fails, inspect that file's HTTP responses.

Read a range request in the browser

This route needs no dashboard for a public video or media you are authorized to read. In Network, open the file's row. In request headers, find Range: bytes=.... In the response, record status and Content-Range. For a single two-byte range at the start of a 2,048-byte file, a consistent partial response gives 206 Partial Content and Content-Range: bytes 0-1/2048. The range is inclusive and the number after the slash is total size when known. A normal download without a range request is expected to return 200.

An HTTP server may ignore Range and deliver the entire file with 200. This can trouble a player requesting a fragment. Accept-Ranges: bytes in another response advertises capability, but the test must examine bytes delivered for the request asking for them. A 206 with wrong bounds or inconsistent length is also a failure. If the request contains If-Range and its condition no longer matches the resource version, the server may return the whole document. Repeat in a fresh session and check a request without that header to distinguish the situations.

For a valid range of a known file, a 416 warrants comparison with actual resource size. This status can be normal if the requested start lies beyond the end. Content-Range: bytes */2048, if sent, gives the length used for the response. A 403, 404 or final login page returning 200 first points to an access or address issue. Also check content type and selected file. text/html instead of MP4 warrants opening redirect details before changing the player.

1. Repeat with browser cache disabled in developer tools. This checkbox affects the browser during inspection. A shared cache may still respond.
2. Find a range request at startup and another after seeking. Compare requested and returned bounds, and record results for the control media.
3. If no request contains Range, the browser may already have enough data or may have chosen another resource. Use an explicit request to test server capability.

Request two fragments with curl

For a public staging video larger than 1,040 bytes, replace the commands' address with the file's. The commands make two GET requests without saving bodies to disk. Use a Bash-style shell. In PowerShell, run curl.exe with the same options for each --range value and replace /dev/null with NUL. The timeout and size limit avoid prolonged download if the server returns the entire file. If curl stops at the limit, read the status and headers received before stopping. Start with a known-size file compatible with this limit.

Read the final header block after redirects. A correct first response contains 206, range 0-1 and two downloaded bytes. The second must contain 206, bounds 1024-1039 and sixteen bytes. The advertised total size must correspond to the same resource in both. Content-Length may be absent. The number of bytes actually read then helps confirm length. The request uses Accept-Encoding: identity to avoid accidentally testing another compressed representation. For a private URL, remain in the browser's authorized session or use the owner's test mechanism. These commands use a public staging URL and no secrets.

If the server returns 200 under these conditions and delivers the entire document, it ignored the range or an intermediate layer changed it. If the file is correct and both fragments match, continue with the address actually used by the player. It may change after the first seek or by device. Checking two fragments evaluates neither video decoding nor network speed.

URL='https://recette.example.test/wp-content/uploads/temoin.mp4'
for PLAGE in 0-1 1024-1039; do
  curl --silent --show-error --location --max-time 15 --max-filesize 1048576 \
    --header 'Accept-Encoding: identity' --range "$PLAGE" --dump-header - \
    --output /dev/null --write-out 'code=%{http_code} octets=%{size_download}\n' "$URL"
done

Isolate the origin, cache or video processing

If you can access hosting configuration, identify what responds for the file. An address under wp-content/uploads/ is often served by the web server. Yet a plugin, external storage system or rewrite rule may send the request to PHP, a signed address or another server. Read the redirect chain and domain configuration. A cache header may indicate where the response passed. It does not prove which component removed the range. Find the effective path in web-server logs or proxy traces at test time.

Compare the same video with the same two ranges at an authorized origin address and the public URL. Check domain, path and file version. If you administer the service and an origin IP is designated for this test, curl can add --resolve recette.example.test:443:192.0.2.10 to the previous options. Replace the example hostname and address with validated staging values. This option retains the URL hostname and certificate verification. The origin must accept the request from your machine. If reachable only from the CDN network, use the host's diagnostic route and change neither DNS nor filtering for the test. Also check that no redirect sends you back to cache before comparing.

A file may change between requests if its URL stays identical after replacement. Compare the available version identifier, such as an ETag on responses from the same server, and total size. Intermediaries may generate different identifiers. If you own the source file and need to settle the comparison, choose a short staging range with known bytes. Save only that response to a working file by replacing output to /dev/null with a local path, then compare bytes with the same source-file segment. Correct length may conceal a fragment from the wrong version. With session-specific variants, repeat from the same session and state whether the discrepancy appears on first access or after cache filling.

If the origin responds correctly and the public response fails, focus on the proxy, cache or storage serving the public object. If both fail, compare with another file on the same path. A video in a public staging folder served directly by the server can provide a control. If that control works but the playback URL fails, inspect processing intercepting that URL. For a protected file, use a dummy file with the same rules. The test must retain the same separation between authorized visitors and those without access.

1. Prepare a comparison using the same file and range at the origin and public access point. Record both addresses and displayed total size.
2. If the addresses serve different versions, first restore a comparison baseline. A 206 for another file does not support a conclusion.
3. If both paths already return correct fragments, test another player or a file encoded in a device-compatible format. Also check the response at the address used at the exact stall moment.

Correct the confirmed path and prepare rollback

For a public MP4 served by Nginx, inspect the configuration block matching its URL. max_ranges 0 disables range support. On Apache, MaxRanges none tells the server to ignore ranges. If you find either setting in the responding location and policy permits range playback, test a rule limited to video paths in staging. A value of 1 permits single-range requests, as in this example. It is not a byte limit. Retain the previous configuration and validate syntax with nginx -t or apachectl configtest, according to server, before applying the host's reload procedure.

If a PHP component or storage service serves video after access checks, use that component's documented range-delivery mechanism. Changing a static-file server's settings will not help if PHP continues returning the entire stream. Ask the maintainer to confirm that processing preserves status, bounds and partial body. For public media, the host-supported static path may work. For private media, also check that direct links and ranges remain inaccessible without required permissions. Avoid adding an Accept-Ranges header to processing still sending the whole file.

If only the CDN fails, consult the setting applying to this media type or path. Compare responses before and after a staging test. Correct the confirmed rule and invalidate this URL's copy through the provider's mechanism. Do not conclude after the first cold access. A second pass verifies correctness when cache is used again. Keep the previous rule and purge location to restore the initial state if another media file stops working.

1. Choose one change based on origin/public-access comparison. Record the target path, old rule and expected result.
2. Repeat both ranges on the corrected path. Also check a plain download and, for protected media, responses with and without read permission.
3. If responses deteriorate or access changes, restore the previous rule, then recheck the same file before trying another correction.

Confirm playback and seeking

Return to the device where failure was observed. Open a fresh session, load the page, start the video and seek to two distinct positions. On the second pass, also test returning to the beginning. Observe responses corresponding to these actions. Depending on bytes already received, every seek does not produce a new request. The goal is to see the player reach chosen positions and verify that range requests actually sent receive consistent responses. Also check a video that worked before the change.

In the final record, note the file version, origin and CDN results, code, bounds and read length for both tests. Identify the browser and device used for playback. If the player fails while fragments and content are correct at the URLs actually requested, examine the codec, player errors and access conditions changing during playback. The protocol test has then ruled out a range fault for those responses. After returning to an earlier rule, repeat the same tests and state which still fails.

Read a partial-response example without confusing sizes

Take a fictional example: the complete video is 50,000 bytes and you request bytes=1024-1039. A consistent partial response carries status 206 and Content-Range: bytes 1024-1039/50000. The body must contain 16 bytes: both bounds are inclusive. The number 50,000 describes the entire file, not the received fragment. Compare these values with files saved by curl without inferring the result merely from Accept-Ranges being present.

If the response is 200 with all 50,000 bytes, the server served the entire file instead of the range. A player may sometimes start despite this; seeking still needs checking. If the response is an HTML login page, even with status 200, you are testing access control rather than an available video.

Browser network tools and curl are free; a player plugin cannot correct the response of the server owning the file. After a hosting or cache correction, repeat both ranges and seeking in a visitor session. If a regression appears, restore only the changed rule, then recheck complete playback.