Remote Access Setup, Verification and Monitoring

1Complete route status2Guided setup3Public HTTPS origin

Finetic's Admin → Remote Access page answers a more useful question than “does the homepage open?”: can an outside client reach the correct Finetic installation and use the request patterns required for sign-in, seeking, HLS playback, live updates and bounded guest access?

Before you begin#

You need:

• administrator access to Finetic;
• an activated Finetic installation, because the independent check is an entitled control-plane service;
• a public DNS hostname such as media.example.com;
• a trusted HTTPS certificate covering that exact hostname;
• a router, firewall or hosted ingress path that reaches your reverse proxy;
• a proxy route that forwards the complete Finetic origin without rewriting /api or media paths.

Use an origin only:

https://media.example.com

Do not enter a private address, a path, a query string, credentials or an insecure HTTP URL.

Run the first outside-home check#

1. Sign in as an administrator.
2. Open Admin → Remote Access.
3. Under Your Finetic address, choose Change if an address is already present.
4. Enter the same HTTPS origin used by browsers, native clients and shared links outside the home.
5. Choose Save and check or Check connection now.
6. Leave the page open until the result appears. A full outside check can take longer than an ordinary API request because it tests several independent routes.

The quick-setup rail tracks three stages: address entered, check completed and any repair still required. A successful result includes the observed public addresses, port 443, certificate evidence, response duration and the timestamp of the check.

What Finetic verifies#

The status, range, manifest, segment and guest routes exist only for a short-lived random probe. Finetic removes the probe after the run or after its ten-minute expiry.

The lower workspace is also captured from the real product. It shows how unchecked evidence remains explicitly pending instead of being presented as a fabricated success.

Read the page from top to bottom#

Connection status#

The summary uses three states:

• Connected — the complete latest route passed and belongs to the currently displayed address.
• Needs attention — at least one observed check failed, or the displayed address differs from the address in the latest report.
• Not checked — no outside-home evidence exists yet.

“Needs attention” does not always mean your home connection is broken. If the local Finetic route passes but the independent checking service returns an error, Finetic labels that service separately and does not invent certificate, DNS or NAT evidence.

What needs fixing#

Finetic orders failed steps and explains the first affected layer. Apply the first repair, then run the complete check again. Later failures can be consequences of the first one.

Connection evidence#

The three overview cards group the detailed result:

• HTTPS covers the certificate and encrypted route.
• Playback routes covers Direct Play seeking, the HLS manifest and segment delivery.
• Guest sharing covers the safe public-link probe.

The expandable Verified connection evidence retains the individual category, safe endpoint, status code and duration reported by the check.

Access overview and history#

The right rail counts successful checks during the last seven and 30 days and identifies the most recent manual or automatic run. Recent check history retains up to 100 reports for this installation; the interface shows the latest ten.

Turn on automatic monitoring#

After a public address is saved:

1. Enable Automatic remote-access checks.
2. Choose every 1, 6, 12 or 24 hours.
3. Run one manual check so the starting evidence is understood.

The scheduler runs the same complete check. If a scheduled run fails, the administrator notification centre receives Fix remote access. When a later check succeeds, Finetic records the recovery and offers View result. Automatic monitoring is disabled by default.

Troubleshoot by failing category#

Reverse-proxy starting points#

Nginx:

location / {
  proxy_pass http://127.0.0.1:3000;
  proxy_http_version 1.1;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
  proxy_request_buffering off;
  proxy_buffering off;
  proxy_read_timeout 3600s;
}

Caddy:

media.example.com {
  reverse_proxy 127.0.0.1:3000
}

These are starting points, not replacements for existing access controls. Do not expose PostgreSQL, Docker, APISIX administration, Proxmox management or another host-management port.

Privacy and security boundary#

The independent check receives the installation identifier, configured public origin and a temporary random proof. It does not receive a media item, password, browser cookie, viewing history, source path or reusable guest link. Diagnostic responses set Cache-Control: no-store.

Public reports are stored in Finetic's PostgreSQL database. The public documentation screenshots are captures from the real Remote Access page in a controlled installation; administrator identity and host details have been sanitized.

Related guides#

• Secure remote-access product guide
• Docker Compose and reverse-proxy deployment
• Collections and secure guest sharing
• Web client and browser playback
• Playback troubleshooting