How do I fix Ortho4XP download/server errors in X-Plane?

To fix Ortho4XP download or server errors in X-Plane, stop the batch, preserve the log, identify the first specific failure, and retry one tile only. Most faults are provider blocks or rate limits, OSM query rejection, SSL or local network filtering, damaged MapCache imagery, insufficient storage, or an unwritable folder—not X-Plane graphics settings.

The same diagnosis applies to Ortho4XP used with X-Plane 11 or X-Plane 12. Ortho4XP retrieves and processes data outside the simulator, so changing rendering settings will not fix an HTTP status, certificate failure or blocked file path.

Does “Ortho4XP download” mean the program or the imagery?

An Ortho4XP download can mean obtaining the program itself or using an installed copy to retrieve source imagery and other tile data.

If the program archive will not download, extract or start, obtain a complete copy through the project’s official distribution route. Extract the entire package to a normal local folder and follow the instructions supplied for that build. Some distributions include more components than others, so setup directions are not interchangeable.

Do not disable operating-system security to run an unverified repack. The troubleshooting below is for a copy of Ortho4XP that opens but fails while retrieving or processing an X-Plane scenery tile.

Which Ortho4XP version should I use?

Use a supported build obtained through the project’s trusted release or documentation route, together with the source definitions intended for that build.

Identify your installed build from its start-up output, window title, included documentation or release metadata. Then compare it with the latest supported release documented by the project—the answer to searches for a última versão, or “the latest version”, should come from that route rather than a random archive.

Do not copy configuration files, source definitions or setup instructions blindly between older releases, newer builds and forks. A definition that worked in one branch may use different syntax or rely on an endpoint that is no longer accepted. Back up your existing configuration before applying an official update, and update only the components the project’s instructions tell you to replace.

What does the first Ortho4XP error mean?

The earliest specific error in the log is usually the cause; messages produced after it often describe build stages that could not continue.

An actual HTTP 504 normally means a remote gateway answered but its upstream service timed out. A local DNS failure usually produces no HTTP response at all. One exception is a managed proxy that generates its own 504; suspect that when unrelated sources fail through the same named proxy or network gateway.

OSM server rejected our query: what does it mean?

“OSM server rejected our query” means a vector-data request was refused; it does not necessarily mean the orthophoto imagery provider failed.

Ortho4XP can request OpenStreetMap or Overpass-style data for features used during tile construction. The service may reject an oversized or malformed query, throttle rapid requests, refuse traffic during heavy load, or stop accepting an obsolete query format from an older definition.

• Stop the batch and retain the complete response. A nearby status such as 400, 403, 429 or 504 changes the diagnosis.
• Wait before retesting. Respect a retry interval when one is supplied. For a 504, make one delayed single-tile attempt.
• Reduce the request load. Test one ordinary tile with conservative concurrency rather than submitting a large region again.
• Check the installed build. Obtain updated definitions only through the project’s trusted release or documentation route.
• Do not evade provider controls. Switching endpoints, rotating addresses or repeatedly resubmitting a refused query can prolong a limit and breaches some providers’ rules.

Clearing the imagery cache will not normally fix an OSM query rejection because vector retrieval and cached source images are separate parts of the build.

How do I fix Ortho4XP download errors step by step?

The safest procedure is to change one thing at a time and use a single tile as the test case.

1. Stop the batch and preserve the log. Find the first useful status or exception, not merely the final red line. Record the source, tile coordinates, stage and any HTTP code.

2. Identify which stage failed. Separate imagery retrieval, OSM or vector retrieval, elevation download, texture conversion and file writing. A completed image download does not prove that the later scenery build succeeded.

3. Retry one tile only. Do not use a whole state or country as a diagnostic test. A single tile limits server load and makes a repeatable failure easier to recognise.

4. Treat HTTP 504 as a delayed retry. If the provider returned 504 Gateway Timeout, wait and try that one tile once. If DNS resolution fails, every source is unreachable or a local proxy identifies itself in the response, investigate the computer or network instead.

5. Compare another area on the same source. If nearby tiles work, the failed location may lack coverage at the requested zoom level. Try a lower zoom level instead of requesting the same missing image repeatedly.

6. Compare another permitted source. If one source fails everywhere while another works, the first provider or its definition is the likely cause. A source appearing in a configuration does not by itself grant permission for automated downloading.

7. Wait and reduce concurrency. Lower simultaneous downloads if your build exposes that setting. After 429, waiting is still required; reducing threads does not cancel an active rate limit.

8. Clean only the failed cache area. Back up the relevant MapCache or source-image cache content, remove entries for the failed source and tile, and run one test. Do not delete completed scenery, elevation data or overlays.

9. Use a simple writable path. Protected system directories, read-only media, cloud-synchronised folders and unusually long paths can interrupt retrieval or conversion. Avoid moving files while a build is active.

10. Check all storage volumes. Cache, temporary files, converted textures and final scenery can reside on different drives. Texture processing may need considerably more space than the original downloaded images.

11. Check local connectivity and SSL. Correct the system clock, inspect DNS and proxy settings, disconnect an unnecessary VPN, and review firewall or antivirus logs. Permit trusted Ortho4XP components rather than disabling protection globally.

12. Resume or rebuild deliberately. Once retrieval works, rerun only the unfinished stages if the existing inputs are known to be sound. Use a fresh tile build when the partial output contains widespread gaps, mixed sources or uncertain build state.

Is the server failing, or is the problem on my PC?

Testing two areas and two valid sources usually separates a remote provider fault from a local computer or network problem.

• One source fails in every area: suspect provider restrictions, rate limiting, service failure or an outdated definition.
• One area fails while nearby tiles work: suspect missing coverage, an unavailable high-zoom image or damaged cache content.
• Every source fails before transferring data: check DNS, proxy, VPN, firewall, system time and certificates.
• Downloads complete but processing fails: check storage, write permissions and texture-processing components.
• The fault comes and goes without local changes: a remote service or the network route is probably unstable.

“This site can’t be reached”, “got error”, SSL error, or “it doesn’t work”

These generic messages are symptoms rather than diagnoses, so the useful evidence is the first detailed line around them.

Localised wording such as não funciona, nem működik or لا يمكن الوصول إلى الموقع الإلكتروني هذا still needs to be traced to a DNS result, HTTP status, certificate message or connection exception. “Got error”, a blank transfer or nothing happening is not enough to decide that the provider is down.

• Confirm the computer’s date, time and time zone are correct.
• Check whether DNS can resolve the provider host and whether failures affect every configured source.
• Review operating-system and application proxy settings, including a proxy imposed by a managed network.
• Temporarily disconnect an optional VPN for the test; do not bypass an organisation’s required controls.
• Check whether antivirus or corporate HTTPS inspection is replacing certificates.
• Inspect firewall and security logs for the Ortho4XP process or the runtime used by that build.
• Test through another permitted network to distinguish the computer from the original connection.

A tile-service URL is often a template rather than an ordinary web page, so opening it directly in a browser is not always a valid provider test. Never solve an SSL error by turning off certificate verification permanently.

Can I clear the cache?

Yes, but clear only the MapCache or source-image cache entries associated with the failed source and tile before making one retest.

1. Close Ortho4XP. Do not remove cache files while they may still be open or downloading.

2. Back up the affected cache section. Folder layouts differ between builds, so preserve anything whose purpose is uncertain.

3. Identify the source and tile. Use the coordinates and provider shown in the log rather than deleting every cached image.

4. Remove only source imagery. Do not delete completed scenery packages, elevation data, generated overlays or unrelated tiles.

5. Run one controlled test. If the same request fails immediately after selective cleaning, the source, definition, coverage or zoom level is more likely at fault than MapCache.

A full purge forces valid imagery to be downloaded again and may trigger another rate limit. Wider cleaning is justified only when unreadable cached files affect many areas and the log consistently identifies cache corruption.

Why did the tile download but not appear in X-Plane?

A tile that retrieved its source imagery but does not appear in X-Plane usually has an incomplete build, incorrect folder placement or wrong scenery_packs.ini order.

MapCache images are build inputs, not finished X-Plane scenery. For X-Plane 12, follow our Ortho4XP tile-building, overlay and installation procedure once all retrieval stages succeed.

• Place the completed scenery package directly in Custom Scenery, or use the appropriate link if it is stored elsewhere.
• Avoid an extra nested folder level that prevents X-Plane from seeing the package.
• Keep airports and local object scenery above generated overlays and orthophoto base mesh entries.
• Remove duplicate or half-built copies of the same tile.
• Read X-Plane’s Log.txt for missing files, failed scenery loads and path errors.

If you use X-Plane 11, our explanation of where Ortho4XP working files and completed scenery belong helps distinguish a real download failure from incorrect package nesting. If a completed X-Plane 12 package loads without an obvious server error but remains invisible, work through the custom photo-scenery visibility and ordering checks.

Do the same fixes apply to X-Plane 11 and X-Plane 12?

Yes; Ortho4XP’s HTTP, OSM, certificate, cache, storage and file-write errors occur outside X-Plane, so the same diagnostic method applies to both versions.

The completed scenery can look different because the simulators render terrain, water and lighting differently. Overlay compatibility and installation details also matter, but those differences do not cause an HTTP 403, 429 or 504.

What should I do when Ortho4XP imagery sources keep failing?

Change to another permitted source when one provider consistently refuses requests or lacks coverage while other sources and your local connection work normally.

Do not change sources merely to evade a temporary 429 limit. Stop retrying immediately after persistent 401 or 403 responses, an explicit OSM rejection, or instructions from the provider to reduce requests. For repeated 500, 502, 503 or 504 responses, one delayed single-tile retry is enough before treating the service as unavailable.

Use only imagery whose provider permits the intended access and use. If no permitted source is available for the location, stop the build rather than bypassing authentication, request limits or technical controls.

Patching is reasonable when one or a few known images are corrupt and the rest of the tile uses the same source, zoom strategy and processing settings. A fresh tile build is preferable when failures are widespread, the source has changed, several build stages are incomplete, cache contents are of uncertain origin, or repeated repairs would mix imagery captured at visibly different dates, seasons, colours or alignments.

For a fresh build, preserve the old tile until the replacement is complete, use one consistent permitted source where possible, and build into a clean output location. This avoids carrying damaged cache entries or half-converted textures into scenery that appears complete but fails later in X-Plane.