Połącz się ze zdalnym serwerem

Każdy klient to renderer działający nad serwerem cc_server, do którego należą dane. Aplikacja desktopowa może uruchomić taki serwer u siebie; aplikacja webowa pod app.usectrl.dev nie może, bo karta przeglądarki nie może hostować serwera. Tak czy inaczej, ten poradnik kieruje klienta na serwer działający gdzie indziej — mały komputer, maszynę wirtualną w chmurze albo serwer budowania.

Wymagania wstępne

Działający cc_server. Jeśli go nie masz, zobacz Uruchom serwer headless.
Albo trzy wartości parowania wygenerowane przez serwer — adres URL serwera (ws://…/rpc lub wss://…/rpc), identyfikator urządzenia i klucz parowania — albo jednorazowy kod zaproszenia od administratora obszaru roboczego. Wykorzystanie zaproszenia zakłada Twoje konto użytkownika, zapisuje Twoje członkostwo i generuje poświadczenie tego klienta za Ciebie, więc nigdy nie musisz posługiwać się identyfikatorem urządzenia ani kluczem.

Upewnij się, że serwer jest osiągalny

Lokalny serwer nie wymaga niczego: ws://localhost:9030/rpc działa zarówno z aplikacji desktopowej, jak i z przeglądarki, bo przeglądarki traktują loopback jako zaufane źródło.

Serwer na innej maszynie to inna sytuacja. app.usectrl.dev jest serwowany przez HTTPS, więc przeglądarka otworzy gniazdo wss:// tylko z certyfikatem, któremu już ufa — a cc_server i tak odmawia powiązania adresu innego niż loopback bez TLS na samym początku. Zapewnij mu jedno z poniższych:

certyfikat bezpośrednio, przez --tls-cert i --tls-key
zakończenie TLS w odwrotnym proxy przed serwerem, przy serwerze uruchomionym z --insecure (plaintext za proxy, wyłącznie w zaufanej sieci)
tunel lub VPN, który dostarcza certyfikat — Tailscale, cloudflared lub podobny. Ustawienia → Serwer → Połączenie i status zawierają wbudowane włączanie tunelu w sekcji Udostępnij ten serwer.

Dwa ustawienia po stronie serwera łatwo przeoczyć. Za proxy, NAT lub tunelem ustaw --public-url na adres, z którym klienci mają się faktycznie łączyć — domyślnie wskazuje lokalne powiązanie, więc bez tego klienci próbują użyć niewłaściwego hosta. A jeśli hostujesz własną kopię builda webowego, dodaj jego origin do --allowed-origins, które domyślnie obejmuje wyłącznie https://app.usectrl.dev; loopback i klienci natywni są zawsze dozwoleni.

Połącz aplikację desktopową

Przy świeżej instalacji:

Uruchom Control Center. Ekran pierwszego uruchomienia pyta Jak ma działać Control Center?
Zamiast Uruchom w tej aplikacji wypełnij pola połączenia: adres URL serwera oraz albo kod zaproszenia, albo identyfikator urządzenia i klucz parowania.
Kliknij Połącz. Control Center łączy się z serwerem i otwiera skrzynkę obszaru roboczego.

W aplikacji desktopowej, która już uruchamia własny serwer:

Otwórz Ustawienia → Serwer → Połączenie i status.
Kliknij Dodaj serwer. Wprowadź adres URL serwera (wss://host:9030/rpc) oraz albo kod zaproszenia, albo identyfikator urządzenia i klucz parowania. Przycisk przyrostka w polu adresu URL wykrywa instancje cc_server w Twojej sieci LAN lub tailnecie.
Kliknij Połącz, a następnie Przełącz w wierszu nowego serwera.

Przełączanie działa na żywo: aplikacja przebudowuje się wokół nowej sesji w miejscu, bez ponownego uruchamiania. Jeśli połączenie się nie powiedzie, pozostajesz na bieżącym serwerze i widzisz błąd. Wiersz serwera, na którym jesteś, nie ma akcji Przełącz; lokalny serwer to pierwszy wiersz, oznaczony Uruchom w tej aplikacji.

Po przełączeniu aplikacja desktopowa nie posiada własnej bazy danych. Każdy ekran czyta i zapisuje przez zdalny serwer za pośrednictwem gniazda WebSocket.

Połącz klienta webowego

Build webowy jest zawsze zdalny.

Otwórz app.usectrl.dev lub własną kopię builda webowego.
Wprowadź adres URL serwera oraz albo kod zaproszenia, albo identyfikator urządzenia i klucz parowania.
Klient łączy się z serwerem i renderuje ten sam interfejs co aplikacja desktopowa.

Jeśli w adresie URL znajduje się bezpośredni link do parowania, pola są wstępnie wypełnione. Klucz parowania jedzie we fragmencie adresu URL, którego przeglądarki nigdy nie wysyłają do serwera hostującego stronę, więc statyczny host nigdy go nie widzi.

Czego przeglądarka nie robi

Klient webowy czyta i zapisuje na tym samym serwerze co aplikacja desktopowa, ale kilka powierzchni wymaga natywnego okna lub urządzeń samej maszyny:

brak systemowych powiadomień typu toast, dźwięków powiadomień i pasa banerów w tle (centrum powiadomień w aplikacji nadal działa)
brak wykrywania serwerów w sieci LAN lub tailnecie w oknie Dodaj serwer
brak czytnika artykułów w aplikacji — artykuły z newsfeedu otwierają się w nowej karcie
brak ponownego uruchamiania podsumowania spotkania i brak anulowania tego, które jest przetwarzane

Dwie funkcje zachowują się inaczej, zamiast być nieobecne. Nagrywanie spotkania działa w przeglądarce: przechwytuje mikrofon oraz udostępniony ekran zawierający ścieżkę audio. Otwórz w IDE też działa, ale prosi serwer o uruchomienie edytora na ekranie serwera, więc przycisk ukrywa się na hoście headless bez zainstalowanych edytorów.

Rozwiązywanie problemów

Przekroczono limit czasu połączenia: serwer musi być osiągalny z klienta. Sprawdź powiązanie (--bind any), czy port jest otwarty i czy --public-url wskazuje adres, z którym klient faktycznie może się połączyć. W otwartym internecie TLS jest obowiązkowy — powiązanie adresu innego niż loopback bez szyfrowania jest odrzucane przy starcie, chyba że serwer uruchomiono z --insecure za proxy.
Przeglądarka odmawia połączenia, ale klient natywny działa: origin przeglądarki nie znajduje się na liście --allowed-origins serwera. Domyślnie dozwolony jest wyłącznie https://app.usectrl.dev (plus loopback).
Klucz parowania odrzucony: uruchom ponownie cc_server pair na serwerze, aby wymienić klucz tego urządzenia, a następnie wprowadź nowy. Odwołane urządzenie stwierdza brak poświadczenia i odmawia połączenia; odwołanie zrywa aktywną sesję w kilka sekund.
Nie ten obszar roboczy: obszar roboczy jest częścią adresu URL (/workspaces/:workspaceId/…) i towarzyszy każdemu wywołaniu, więc przełączenie obszaru roboczego w jednym kliencie zmienia tylko Twój własny widok. Możesz sięgnąć wyłącznie do obszarów roboczych, których jesteś członkiem — wszystko inne jest odrzucane komunikatem “Not a member of this workspace”. Zobacz Obszary robocze i izolacja.

Powiązane poradniki

Uruchom serwer headless
Sparuj urządzenie: ścieżka przekazywania przez telefon