SSO/OIDC Issues

[DRO34]

My proxcenter is behind a reverse proxy with FQDN and Cert via nginix, working fine.

When i go to setup SSO/OIDC via DUO i notice proxcneter is passing the Internal IP address as the URL.. How do i change this to present the FQDN to DUO so it matches the request? This redirect URI will need to be the FQDN because after you make the login request and approve SSO to provision the user it will timeout looking for the IP as it obviously can't reach that.

Is there a setup guide for this somwhere? Thanks

also, since it is semi related to this. Is there a way to add some kind of 2fa auth to the local super admin account? Once i get SSO working, there needs to be a way to secure this local admin account for backdoor access with a long password string and some kind of 2fa like ttop.. or turn it off somehow so only sso works.

[adminsyspro]

Hi @Trembler34,

Both issues come down to the same thing: NEXTAUTH_URL.

NextAuth derives the OIDC redirect_uri it sends to DUO (and the session/CSRF cookies' Secure flag) from whatever NEXTAUTH_URL is set to inside the container. The Docker installer writes that value when you first run it, and if the host was reached by IP at that moment, it'll be the internal IP that gets shipped to DUO. Nothing in the request-time Host / X-Forwarded-* headers will override it.

Fix:

1. Edit /opt/proxcenter/.env on the host and replace the NEXTAUTH_URL line with your public FQDN (the same URL you hit in the browser through nginx), for example:

   NEXTAUTH_URL=https://proxcenter.example.com
   

2. Restart the stack:

   cd /opt/proxcenter && docker compose up -d

3. In the DUO admin console, set the Redirect URI to that same URL plus /api/auth/callback/oidc (or whatever provider id you configured). It must match exactly: scheme, host, no trailing slash mismatch.

4. Make sure your nginx vhost forwards the right headers so cookies stay valid:

   proxy_set_header Host $host;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_http_version 1.1;
   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection "upgrade";

We saw the same root cause in discussion #182 (different symptom there, login was failing silently because of the same URL mismatch). We should make the installer prompt for the public URL by default, will track that.

On your second question (2FA on the local super_admin, or disabling local login once SSO works): neither is implemented today. The 2FA section you see in Settings is the pass-through for Proxmox VE's own TFA settings, not for ProxCenter accounts. Local-account 2FA / TOTP is tracked in #140, and "SSO-only mode" isn't on the roadmap yet but it's a fair ask, feel free to open a feature request and we'll line it up alongside #140.

Thanks!

[DRO34]

It seems to break things when i change the URL.. Here is what happens.

When i change the nextauth URL from http://ip:3000 to https://fqdn

The NGINIX proxy no longer works, also trying to connect to proxcenter from the internal IP, the page pulls up but you cannot authenticate into the instance. It will not take the credentials. As soon as i put things back everything works as it should.

It seems as if the proxy can no longer recognize proxcenter on that internal IP to route traffice from http://ip to https://fqdn and therefore breaks the proxy. but the more concerning aspect of it is that you can't even login directly via IP anymore so it seems to be a two part issue created by changing the URL.

[DRO34]

EDIT to the above : so it seems the issue stems from this. It does not like something from here

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Soon as i remove it i can access the instance as before from the URL but cannot login via the internal IP, i think this is to be expected (maybe not?)..

However, SSO does not work. Here are the errors from the log. Token not present.. Ideas?

proxcenter-frontend | (node:1) [DEP0169] DeprecationWarning: url.parse() behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for url.parse() vulnerabilities.
proxcenter-frontend | (Use node --trace-deprecation ... to show where the warning was created)
proxcenter-frontend | [next-auth][error][OAUTH_CALLBACK_ERROR]
proxcenter-frontend | https://next-auth.js.org/errors#oauth_callback_error id_token not present in TokenSet {
proxcenter-frontend | error: Error [OAuthCallbackError]: id_token not present in TokenSet
proxcenter-frontend | at Y.validateIdToken (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:6640)
proxcenter-frontend | at Y.callback (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:3008)
proxcenter-frontend | at async l (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:59995)
proxcenter-frontend | at async Object.c (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:64456)
proxcenter-frontend | at async _ (.next/server/chunks/[root-of-the-server]__0ka1swc..js:34:19803)
proxcenter-frontend | at async a (.next/server/chunks/[root-of-the-server]__0ka1swc..js:34:44565)
proxcenter-frontend | at async e.length.t (.next/server/chunks/[root-of-the-server]__0ka1swc._.js:34:46009) {
proxcenter-frontend | code: undefined
proxcenter-frontend | },
proxcenter-frontend | providerId: 'oidc',
proxcenter-frontend | message: 'id_token not present in TokenSet'
proxcenter-frontend | }

[adminsyspro]

Update on the local-2FA portion of your second question, @Trembler34.

Local TOTP two-factor authentication has shipped on main (merged via #351). It's now available for both credentials and LDAP accounts. OIDC accounts still rely on their identity provider (DUO in your case), which is the right boundary.

What you get out of the box:

• Profile > Two-Factor Authentication: opt-in TOTP wizard with QR code + 10 one-shot recovery codes (download as .txt before closing the wizard).
• Sign-in step-up: after the password is accepted, a small dialog asks for the 6-digit code. You can also use a recovery code in the same field.
• Admin policy: Security > Compliance > Policies has a new "Require 2FA for super_admin accounts" toggle. The toggle is gated: you must already have 2FA on your own account to enable it (foot-shoot guard).
• Per-user enforcement: from Security > Users, super_admins can require a specific user to enroll on their next sign-in, or cancel a pending requirement. Also a recovery action that disables 2FA on a user who lost both authenticator and recovery codes (the lockout-rescue path you mentioned).
• Replay defense: RFC 6238 §5.2 high-water-mark, so a captured 6-digit code can't be replayed within its 30-second window.
• Audit trail: every enroll, disable, recovery-code use, and admin action is logged under category auth.

Docs: https://github.com/adminsyspro/proxcenter-docs/blob/master/docs/security/two-factor-authentication.md

This is on top of the OIDC reverse-proxy NEXTAUTH_URL fix from my first reply, which is the immediate unblocker for your DUO setup. Once your sign-in is going through the FQDN, your DUO MFA handles the second factor for the OIDC path, and ProxCenter's local TOTP covers the backdoor super_admin account you wanted to harden.

Available in the next release. Let us know if anything is off.

[DRO34]

awesome that is perfect.. Is that also going to fix the issue i have above with the Token?

[adminsyspro]

Two separate things here, neither related to 2FA, @Trembler34.

1. The nginx Upgrade / Connection headers

The proxy_set_header Connection "upgrade" line only makes sense when $http_upgrade is also propagated through a map block at the top of nginx.conf. Without that map, Connection is set to the literal string "upgrade" on every request, which breaks plain HTTP fetches like the OIDC token POST. That is most likely what was failing.

Two clean ways out:

Option A add the standard map block at the top of /etc/nginx/nginx.conf (inside the http {} context) so the headers only fire on real WebSocket upgrades:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Then in your site config, change Connection "upgrade" to Connection $connection_upgrade. Restart nginx. Your existing block becomes:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

This keeps the noVNC and xterm.js consoles working (they use WebSockets) and stops breaking the regular requests.

Option B if you do not need the in-app consoles, drop those two Upgrade / Connection lines entirely. Keep Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto. ProxCenter itself does not need the WS headers for the sign-in flow.

I will update the install doc to use the map form by default since it is the safer template.

2. id_token not present in TokenSet

This OIDC callback error means DUO returned the OAuth token response without an id_token field. NextAuth refuses to continue because we configure the provider with idToken: true (we rely on the id_token to read the user claims).

Almost always it is the Scopes field on the OIDC settings page. The OIDC spec only returns an id_token when the request includes the openid scope. Check the value on Settings > Authentication > OIDC > Scopes: it should be at least

openid profile email

If it is set to just profile email (the openid prefix dropped), DUO will give you an access_token only and the callback will fail with exactly the error you posted.

If openid is already in there, the next things to check on DUO's side:

1. The application type is "Web SSO with OIDC" (not "OAuth 2.0 client").
2. The grant type is authorization_code (not client_credentials).
3. Your DUO admin panel exposes the userinfo_endpoint and id_token_signed_response_alg in .well-known/openid-configuration. You can fetch it with curl https://<your-duo-issuer>/.well-known/openid-configuration to confirm.

If you paste that .well-known JSON I can tell you exactly what to adjust.

[DRO34]

Right now i am using Open ID and Email, no profile. We use everything through Email Address. The application type in DUO is set to Generic OIDC SSO which should support everything we need here.

Here you go, JSON, certain things omitted

{"issuer": "https://issuer, "authorization_endpoint": "https://issuer/authorize", "token_endpoint": "https://issuer/token", "jwks_uri": "https://issuerjwks", "response_types_supported": ["code"], "subject_types_supported": ["public"], "id_token_signing_alg_values_supported": ["RS256"], "introspection_endpoint": "https://issuer/token_introspection", "userinfo_endpoint": "https://issuer/userinfo", "scopes_supported": ["openid", "email"], "response_modes_supported": ["query", "fragment"], "grant_types_supported": ["authorization_code"], "token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post"], "introspection_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post"], "code_challenge_methods_supported": ["S256"], "client_id_metadata_document_supported": false}root@aid-proxcenter:/opt/proxcenter#

[adminsyspro]

Two things in your reply point at the same root cause, @Trembler34.

The scopes field is case- and space-sensitive.

You wrote "Open ID and Email". If that is literally what is in Settings > Authentication > OIDC > Scopes, it is the bug. OIDC scope values are bare tokens, space-separated, lowercase. DUO's own discovery doc you pasted confirms it:

"scopes_supported": ["openid", "email"]

Open ID is not in that list, only openid is. When the authorize request goes out without the literal token openid, DUO treats it as a plain OAuth2 flow, hands back an access_token for the email scope, and never issues an id_token. That is exactly the id_token not present in TokenSet error you see.

Fix: set the Scopes field to:

openid email

(lowercase, single space between, no commas, no "and"). Save, sign out, retry.

You can verify what is actually being sent by watching the URL in the address bar at the moment DUO loads. The scope= query parameter on /authorize?... should contain openid%20email. If it shows Open%20ID%20email or OpenID%20Email, that confirms the typo.

The rest of your discovery doc is fine for our setup:

• response_types_supported: ["code"]: matches, we use authorization_code.
• id_token_signing_alg_values_supported: ["RS256"]: matches NextAuth's default.
• token_endpoint_auth_methods_supported includes client_secret_basic: matches NextAuth's default.
• code_challenge_methods_supported: ["S256"]: fine, we do not enforce PKCE.

The Generic OIDC SSO application type in DUO is correct. No DUO-side change needed once the scope string is fixed.

[DRO34]

DUO automatically populates these fields. I did not type anything in.. Here is how it looks in DUO..

openid is selected by default and greyed out as you cannot change it

Here is what it is in proxcenter now.. I just added openid it only had email listed there..

[DRO34]

that change still generates the oauth error

[adminsyspro]

DUO is sending openid + email with the right claim mapping, and ProxCenter is asking for openid email with email and name as claim names. That part is settled.

The red OAuthCallback banner is NextAuth's generic catch-all code for "something blew up in the callback handler". The actual cause is in the container log, same place we found the previous id_token not present in TokenSet line. Could you grab the new log line for the most recent attempt and paste it here:

docker compose -f /opt/proxcenter/docker-compose.yml logs --tail=200 proxcenter-frontend | grep -A 20 -iE 'oauth|next-auth|oidc'

While you do that, two things worth checking in parallel that often cause this exact symptom once the scope fix is in:

1. Stale state cookie from the previous failed flow. NextAuth sets a short-lived cookie at the start of the sign-in to validate the callback. Cookies from your earlier attempts (before the NEXTAUTH_URL change and before the scope fix) are still in your browser and can fail the validation step on the callback. Open a private window or clear cookies for the ProxCenter FQDN, then retry from a clean state.

2. X-Forwarded-Proto on nginx. If you ended up trimming the nginx proxy_set_header block to drop the Upgrade / Connection lines, double-check that X-Forwarded-Proto $scheme; survived. Without it, the container thinks the request came in over HTTP, builds the callback URL with http://..., and the state validation rejects the round-trip because the URL it sees does not match the URL the cookie was set on.

   Minimum block that should be in your site config:

   proxy_set_header Host $host;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;

3. NEXTAUTH_URL actually applied. After editing /opt/proxcenter/.env, you need docker compose up -d (not just restart) to pick up the new env value. Confirm with:

   docker compose exec proxcenter-frontend printenv NEXTAUTH_URL

   It should print your public FQDN with https://. If it still shows the IP or http://, the container is running with the old value.

The log line will narrow it down to one of those (or a different cause). Paste it and we will close this out.

[DRO34]

no such service - Seems odd, i am able to get to proxcenter and use it with no issues outside of SSO.
Rebooted container as well.

Confirmed NGINIX, all matches up.

nextauth URL looks good if i manually check the .env file and also if it wasn't working i wouldn't be able to have DUO see it, which it does. The oauth is unrelated to that first issuer claim error message i had. But this command also generates frontend not running

[adminsyspro]

That's my mistake on the service name, sorry. The service inside docker-compose.yml is just frontend, the proxcenter-frontend you see in docker ps is the container_name. Two different identifiers. Replace proxcenter-frontend with frontend in both commands and they will work:

docker compose -f /opt/proxcenter/docker-compose.yml logs --tail=200 frontend | grep -A 20 -iE 'oauth|next-auth|oidc'

docker compose -f /opt/proxcenter/docker-compose.yml exec frontend printenv NEXTAUTH_URL

Or, working off the container name with plain docker:

docker logs --tail=200 proxcenter-frontend | grep -A 20 -iE 'oauth|next-auth|oidc'
docker exec proxcenter-frontend printenv NEXTAUTH_URL

You are right that NEXTAUTH_URL is almost certainly fine since DUO is already reaching your FQDN, that check is just a belt-and-braces step we can skip if you have already eyeballed .env. The thing we still need is the actual log line from the frontend container at the moment of the failed callback. It will be a [next-auth][error] line, same shape as the id_token not present in TokenSet one you posted earlier but with a different error code this time. Paste that and we will know which sub-step is failing.

[DRO34]

yep .env looks good.

Here is the log - issuer specifics omitted with - issuer
node IPs removed labeled as node1,2,3
string removed with - string

root@aid-proxcenter:/opt/proxcenter# docker compose -f /opt/proxcenter/docker-compose.yml logs --tail=200 frontend | grep -A 20 -iE 'oauth|next-auth|oidc'
proxcenter-frontend | [next-auth][error][OAUTH_CALLBACK_ERROR]
proxcenter-frontend | https://next-auth.js.org/errors#oauth_callback_error unexpected iss value, expected undefined, got: https://issuer/oidc/string {
proxcenter-frontend | error: Error [OAuthCallbackError]: unexpected iss value, expected undefined, got: https://issuer/oidc/string
proxcenter-frontend | at Y.validateJWT (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:8990)
proxcenter-frontend | at Y.validateIdToken (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:6762)
proxcenter-frontend | at Y.callback (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:3008)
proxcenter-frontend | at async l (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:59995)
proxcenter-frontend | at async Object.c (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:64456)
proxcenter-frontend | at async _ (.next/server/chunks/[root-of-the-server]__0ka1swc..js:34:19803)
proxcenter-frontend | at async a (.next/server/chunks/[root-of-the-server]__0ka1swc..js:34:44565)
proxcenter-frontend | at async e.length.t (.next/server/chunks/[root-of-the-server]__0ka1swc..js:34:46009) {
proxcenter-frontend | code: undefined
proxcenter-frontend | },
proxcenter-frontend | providerId: 'oidc',
proxcenter-frontend | message: 'unexpected iss value, expected undefined, got: https://issuer/oidc/string'
proxcenter-frontend | }
proxcenter-frontend | [failover] Discovered 3 node IPs for connection cmp2nfzuk000001pvmibg0ooh: node1, node2, node3
proxcenter-frontend | [inventory-stream] Streamed all data in 748ms
proxcenter-frontend | [next-auth][error][OAUTH_CALLBACK_ERROR]
proxcenter-frontend | https://next-auth.js.org/errors#oauth_callback_error unexpected iss value, expected undefined, got: https://issuer/oidc/string {
proxcenter-frontend | error: Error [OAuthCallbackError]: unexpected iss value, expected undefined, got: https://issuer/oidc/string
proxcenter-frontend | at Y.validateJWT (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:8990)
proxcenter-frontend | at Y.validateIdToken (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:6762)
proxcenter-frontend | at Y.callback (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:3008)
proxcenter-frontend | at async l (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:59995)
proxcenter-frontend | at async Object.c (.next/server/chunks/[root-of-the-server]__0ka1swc..js:10:64456)
proxcenter-frontend | at async _ (.next/server/chunks/[root-of-the-server]__0ka1swc..js:34:19803)
proxcenter-frontend | at async a (.next/server/chunks/[root-of-the-server]__0ka1swc..js:34:44565)
proxcenter-frontend | at async e.length.t (.next/server/chunks/[root-of-the-server]__0ka1swc..js:34:46009) {
proxcenter-frontend | code: undefined
proxcenter-frontend | },
proxcenter-frontend | providerId: 'oidc',
proxcenter-frontend | message: 'unexpected iss value, expected undefined, got: https://issuer/oidc/string'
proxcenter-frontend | }
proxcenter-frontend |
proxcenter-frontend | [start] SIGTERM received, shutting down...
proxcenter-frontend | [start] Server closed
proxcenter-frontend | [entrypoint] Applying Prisma migrations...
proxcenter-frontend | Loaded Prisma config from prisma.config.ts.
proxcenter-frontend |
proxcenter-frontend | Prisma schema loaded from prisma/schema.prisma.
proxcenter-frontend | Datasource "db": PostgreSQL database "proxcenter", schema "public" at "postgres:5432"
proxcenter-frontend |
proxcenter-frontend | 5 migrations found in prisma/migrations
proxcenter-frontend |
proxcenter-frontend |
proxcenter-frontend | No pending migrations to apply.
proxcenter-frontend | [entrypoint] Running idempotent seed...
proxcenter-frontend | [seed] starting?
proxcenter-frontend | [seed] tenant 'default' ?
proxcenter-frontend | [seed] security_policies singleton ?
proxcenter-frontend | [seed] 52 permissions ?
proxcenter-frontend | [seed] 9 system roles + permission mappings ?

[adminsyspro]

Good news first, @Trembler34: we're past the scope problem. The new log line is openid-client's iss validation step, and the expected undefined part is the actual clue.

What's happening

When the OIDC config in ProxCenter has the manual override URLs filled in (Authorization URL, Token URL, Userinfo URL), our backend skips OIDC discovery and constructs the provider from those URLs directly. The issuer metadata never gets loaded, so NextAuth's id_token validator has nothing to compare the iss claim against. That's why the message reads expected undefined instead of an actual URL.

DUO's id_token claims iss: https://<sso-host>/oidc/<client_id>, which is correct per spec (DUO uses one issuer per application). ProxCenter just had no way to know that without running discovery.

Fix on your side

In Settings > Authentication > OIDC:

1. Leave Issuer URL set to the FULL DUO issuer, including the /oidc/<client_id> suffix (same string that shows up in the failed log line).
2. Clear the three override fields: Authorization URL, Token URL, Userinfo URL. Leave them blank.
3. Save. ProxCenter will then call <issuer_url>/.well-known/openid-configuration, read DUO's canonical issuer, and the iss check will line up.

Scopes (openid email) and the claim names you already corrected stay as they are.

Fix on our side

We're patching this in v1.4.2 so the manual-override path passes the issuer through to NextAuth explicitly. That removes the foot-gun for anyone who copy-pastes all four URLs from the discovery doc.

Let us know once the override fields are cleared. The next failed callback should either succeed or produce a real iss mismatch line we can read.

[DRO34]

There we go! Clearing the Override fields seems to have fixed it.. Now i can login fully with SSO and have it provision my account.

[adminsyspro]

Perfect, glad that did it, @Trembler34.

For the record so the thread is self-contained: the override fields under Advanced Endpoints (Authorization URL, Token URL, Userinfo URL) are optional. With them blank, ProxCenter uses Duo's .well-known/openid-configuration discovery, which carries the canonical issuer and makes the id_token iss check pass. With them filled in (on v1.4.1 and older) the issuer was never loaded, which is why you saw expected undefined.

We've patched that path for the next release (v1.4.2): the configured Issuer URL is now passed through even when the override fields are populated, so the foot-gun is gone either way. Docs are being updated to call this out too.

Since your Duo MFA fires at the OIDC step, your sign-in is now fully covered, and the local super_admin TOTP from #351 is there for the backdoor account you wanted to harden. Closing this out, reopen if anything resurfaces.

[DRO34]

Thank you.. Also, you mentioned something about the nginix server block above for the VNC console. The VNC console performance is terrible. We get no mouse emulation at all. We use SPICE for everything with Guest tools/plus QEMU agent. Works fine outside of proxcenter. We have websocket support and proper configuration, at least we believe so.. Do you want me to create a new thread or you can just answer here since it was part of the block a few comments up? I know this is all new terrortory with this configuration on my end.

Here is what this proxy host is supporting

Cache Assets
Block Common Exploits
Websockets Support
HSTS
HTTP/2 Support
HSTS Sub-Domains
Trust Upstream forwarded Proto Headers- Disabled

[adminsyspro]

ProxCenter's console is noVNC (VNC over WebSocket), not SPICE. It is the same console as the "noVNC" button in the Proxmox web UI. SPICE has no in-browser renderer anywhere (not in ProxCenter, not in upstream Proxmox): it needs a native client (virt-viewer / remote-viewer) opening a .vv file. So "works fine outside ProxCenter" is you using a native SPICE client. In any browser console you are on VNC regardless of the VM's display setting.

The missing mouse emulation is the USB tablet device. noVNC needs a USB tablet (absolute pointer) to track 1:1. With the display set to qxl/SPICE and the tablet off, VNC falls back to a relative pointer, which is exactly your symptom. Fix: VM > Hardware, enable USB Tablet (or tablet: 1 in Options), then reopen the console.

For smoother performance, a qxl display tuned for SPICE feels sluggish over the VNC path. Try Standard VGA (std) or VirtIO-GPU for the in-browser console.

True SPICE (audio, USB redirection, multi-monitor) stays a native-client workflow against the host. We do not render SPICE in-browser today. A "download .vv / open in virt-viewer" button is a fair feature request if your team would use it, happy to line it up.

[DRO34]

Thanks for information, yes we use spice for video emulation as it has the best performance when remoting into the VMs from something like screenconnect and in general when using the console it works fine too. I should have been more clear. It seems the VNC performance has only gotten bad since setting up the reverse proxy with proxcenter. Using it on the local IP we didn't really notice the performance being as bad.. We also didnt have the issue with no mouse eumualtion. Let me try your fix above to see if that helps.

What would you suggest i set it to so we have a good balance of performance from both the console and physically remoting into the VMs using our remote connection software and do you believe there may be some tweaks over the reverse proxy?

[DRO34]

I checked and it looks like we already have tablet enabled

[DRO34]

Oh and yes, a download for a viewer would be great as well. That is pretty common to see with vcenter etc.. so that would be great. I think that will be the answer to all of this so we can render spice from both the console viewer and in our remote connection software tools..

[adminsyspro]

Tablet is set, so we can rule out the absolute pointer. With the reverse proxy in front, what you are seeing as "no mouse emulation" is almost certainly proxy buffering: nginx (and Nginx Proxy Manager) default to proxy_buffering on, which batches WebSocket frames before forwarding them. On a screen-scrape protocol like VNC the visible result is exactly your symptom: cursor drags, clicks land late, the absolute pointer feels broken even though QEMU is sending it correctly.

On plain nginx, add this inside the location that holds the ProxCenter proxy_pass:

proxy_buffering off;
proxy_request_buffering off;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;

On Nginx Proxy Manager (your toggles above look like NPM), the same four lines go into the proxy host's Advanced tab, under Custom Nginx Configuration. The host reloads on its own.

The two *_buffering off switches restore the live cursor feel. The two timeouts keep an idle WebSocket from being killed at the default 60s (the usual cause of "the console froze, I had to reopen it").

Keep Trust Upstream Forwarded Proto Headers disabled as you have it. That toggle is for ProxCenter behind a chain of proxies, which is not your case, and turning it on with a single hop would let a client spoof X-Forwarded-Proto.

[DRO34]

Thank you, will test this out later on. I would still love to see an external viewer as well if you can add that and Yes we use NPM with CrowdSec its actually a fantastic setup.

[adminsyspro]

Indeed, I use it too on other projects, great tools !

[adminsyspro]

On the inventory tree header collapsing the whole section when you click it to see the infrastructure-health dashboard: tracked as #366, will go out in the next release. The PROXMOX VE (and NETWORK) header will be select-only, with the + / - icon on the left as the sole collapse control, matching the Storage / Backup / Migration headers.

[DRO34]

Thank you!