Ich glaube hier gibt es noch ein grundsätzliches Verständnisproblem. Der Proxyserver liefert technisch gesehen keine Seiten von CiviCRM aus. Er nimmt nur „Anfragen“ entgegen (z.B. die Links in den Newslettern oder API-Calls) und leitet diese an Civi weiter. CiviCRM ist in einem gesicherten Netzwerk und daher für Externe gar nicht zu erreichen.
Der Proxyserver hat zudem noch zwei einfache, eigene Formulare um sich von Newslettern abmelden bzw. einen Opt-Out machen zu können. Hier auch nochmal ein Link zur Doku, die Ihr aber vermutlich schon kennt.
Hier mal ein Beispiel:
- CiviCRM läuft unter civicrm.example.com
- der Proxy-Server läuft unter civiproxy.example.com
Wenn Ihr jetzt einen Newsletter verschickt zeigen die Links die eigentlich auf civicrm.example.com zeigen würden auf civiproxy.example.com - ebenso die nachzuladenden Bilder des Newsletters (das macht die CiviProxy-Extension).
Der Proxy-Server liefert die Bilder aus, regelt dass man auf den Ziellink kommt usw. Wenn jemand auf unsubscribe oder opt-out in der Mail klickt, kommt man zu einem Formular des Proxyservers auf civiproxy.example.com wo man das machen kann.
Wenn Euch das reicht ist das gut und Euer Proxyserver kann eine beliebige, „öffentlichkeitstaugliche“ Domain haben.
Für alle anderen Funktionen / Formulare braucht man i.d.R. ein drittes System, bspw. selfservice.example.com (wir nennen das oft „öffentliches Frontend“). Dort kann es dann beliebige Formulare etc. geben mit denen „Externe“ dann interagieren. Diese System schickt alle Daten an den Proxy, welcher dann wiederum mit CiviCRM im sicheren Netzwerk agiert.
Wenn dieses dritte System Drupal ist gibt es schon einige Module, die recht einfach genutzt werden können. Ein Beispiel ist Remote Events - dessen Setup z.B. hier beschrieben wird. Im Bereich Newsletter / Präferenzenverwaltung gibt es bspw. Advanced Newsletter Management.
Wenn das dritte, öffentliche System nicht Drupal ist muss man eine eigene Lösung dafüpr entwickeln. Ich hoffe, das hilft 