This page covers the main upload and delivery behavior users feel directly.

fyuhls supports:

• chunked uploads
• duplicate detection
• remote URL uploads
• package-based limits
• extension allowlists
• local-storage multipart uploads through the app when a local node is active
• a download-page save action for signed-in users when enabled by config
• the public Link Checker utility when enabled by the admin

Downloads can be:

• app-controlled
• CDN redirected
• signed-origin object delivery
• Nginx, Apache, or LiteSpeed handoff

The app decides the actual path based on:

• file visibility
• storage backend
• download settings
• package rules
• verification and progress requirements

Human-facing download pages now share more of the same shell and state rendering. That matters because users should see a more consistent experience across:

• normal file pages
• unavailable file pages
• blocked or protected download states
• link-expired or session-expired states

• shared download pages now use a cleaner internal architecture with reusable partials
• daily limit states and download state pages are more consistent
• file-manager bulk behavior is better
• upload errors are clearer than the older generic failure path
• local storage now works with the modern multipart uploader instead of failing with the older multipart-support mismatch
• download/share behavior is more consistent with current page links and share fields
• download-like blocked or denied pages now stay more aligned with the normal download page layout and ad behavior
• private or missing files can be presented through a more generic unavailable state instead of exposing too much about why a link cannot be used

Current file-manager behavior includes:

• bulk selection and actions
• search and filter chips
• largest-first sorting
• live updates for several actions
• cleaner grid/list handling

• upload a small file
• upload a large file
• try a blocked extension
• test a public download page
• test a private or protected download path
• test one file-manager download action
• if using Local Storage, test one real multipart upload larger than a single chunk
• if using remote object storage, test both connection and one real browser upload
• if using download-page save actions, test one signed-in save-to-account action for the user types you enabled

If uploads stall or error:

• check package limits
• check storage health
• check CORS for object storage
• check whether the node is local storage vs remote object storage
• check System Status and background jobs

If the failing install uses Local Storage, do not assume a Wasabi, B2, or R2-style bucket problem. Local storage now uses an app-routed multipart path, so local permissions and route availability matter more than bucket CORS.

If ordinary users say "the download page changed" or "ads disappeared on one error page but not another," check whether that path is still using the shared download-state renderer before assuming the ad code itself is broken.

If you rely on concurrency-sensitive or payout-sensitive download behavior, also verify:

• active download tracking
• completion logs
• cron ingestion jobs
• the delivery diagnostics section in System Status

Download eligibility can now be influenced by the current VPN/proxy mode:

• None: no ProxyCheck lookup and no VPN/proxy blocking
• Enforcement: suspicious VPN/proxy traffic is blocked before the normal download flow continues
• Intelligence: ProxyCheck is queried for scoring and fraud context without blocking by itself

For public-facing safety, unavailable private or deleted links should be treated as unavailable rather than as a rich disclosure surface.

For most operator changes in this area, you will move between:

• Config Hub > Uploads
• Config Hub > Downloads
• Config Hub > Link Checker
• Storage Nodes
• Packages
• System Status